Learning in public is grand, and when you have a team that is willing to help with something that seems simple, but you fall into overthink for the wrong items, it can really help to type out your thoughts, actions, and what the program does to frustrate you. And in this case, getting a value I could see in the debugger was the issue

The automation needs to check for page elements – and the drop-down selector triggers potentially different elements. Plus, depending on the user logged in, there may well be different options available in that drop-down. Then, I can get the options available for the user on the drop down, get their values, cycle through them, and verify each set of elements on the page.

My test account for this has four options on the drop-down, so I budgeted a couple of hours to get each step done. Getting the contract was somewhat easy: the drop-down is a select element, so QuerySelectorAllAsync() with option as the items I wanted to get was only slightly frustrating. I think this is my first time working with IElementHandles, but if they are all this easy, then I’m good! I had hard-coded a specific option for a previous test, so I knew the information I needed. And to make sure, I checked with that hard-coded information – and yes, this works!

Well, I THOUGHT I was good – to make sure I had the correct information (we had just updated the certificate, so there was a better option for connecting to the environment) I added extra items to the drop-down for the test account. Being newer to C Sharp, I didn’t know what effect the change would have, but wanted to make very sure that the information I had returned was correct! It turned out that one of the changes updated the SqlConnectionString I’m using: I was pulling from the wrong environment! One of the developers kindly took the time to look at my code, and to verify that it was correct. We kept looking, and they checked the connection string. That turned out to be the issue, and thankfully, it was a simple correction I could do without having to ask for assistance. I did ask, then figured it out while waiting for the meeting to start.

Step 1 is done: I can access the correct data. Getting the user information was a more-familiar process for me. This is a “match the email to the user ID” call and assign it to a variable. I’m doing these tests in small steps, and this will be used many times. I decided to keep the code a bit cleaner. There are going to be several methods that access user-specific information, so they are going to be tucked away in their own class. It will make future code-reading easier, and hopefully more organized.

I now know my user’s id, and the drop-down options that are available. It’s time for the one I’m hoping will be easy: cycling through the options. I knew a foreach loop was a decent choice for now. It may not be the correct choice longer-term, but I’m approaching this with the “Make it work, then make it pretty” attitude. And the system complained at me. It wanted to know what would happen if the selectors were null. And this was a reasonable thing, but I wanted to complete the task! So off to a rabbit hole of “how to do a null check”. This turned out to be a simple one-line update that would use the data and to use a hard-coded value that was a default option if there happened to be no data (and an urgent log message to be sent!).

Some research, and it seems that EvaluateAsync(value => value.textContent should give me the information I need! And it didn’t. Running it with the debugger (and a break point on the next line) shows that it gives me the text shown in the drop-down, but not the value. Looking at what’s evaluated shows that it’s doing what I asked. Now to figure out how to get it to do what I want! I can see the value in the debugger, under preview – now how to get it?

Some research into JSHandle@ showed me yet another area I need to focus on for skilling up. And several other attempts to get the correct information. It’s been a generous 45 minutes: it’s time to ask for help, again. A different one of the developers has a few moments, and I see the typing indicator. It’s almost at the point that I worry.

It seems that a lambda is used to be able to input more-complex functions – something that one of the team was not familiar with. But, as I suspected, I was using the wrong value types to get the correct answer. A quick change to select => select.value got me the information I needed!

Now to get the rest of the section to accept this information. The original hard-coded statement had that value, including the semicolon, in the statement. Using it as a variable, the system is complaining about the semicolon. I’m going to try and use Regex to get the value before the semicolon, and input that. But first, I think another cup of coffee is called for.

I’m not happy with how I’m coding this, and the coffee helped. I have two lambdas being passed, so I’m going to try and combine them, and see it things will work. And so far, it looks promising. And it worked! Other than my foreach loop, but that’s a problem for another session.