I am working on earning my SDET title - and have made some progress. I'm slowly catching up on the manual tests that we need and starting some automation. One thing that is slowing me down is there are no records of requirements for many of the features of the application, so I'm diving into legacy code, teasing out what should happen "if". Some of them are obvious - if you try and log in with a correct account, you should be given access at that level. But very few are this simple, and planning for tests and time with people who have helped the system grow into the way it is has been a challenge all by itself.
The first automation I wrote checks the log in page - a simple task. There had been recent changes, but the tests have finally been code-reviewed to be placed into the pipeline. Still reeling from this, I started the next series of tests. These were more challenging: the page that any user would open after logging in. I have been discovering Playwright, and teaching myself the C# that we use at work, so I was far from an expert at any of this. Following our plan to make sure that the items that have been reported are considered for automation, I located a simple thing to add for check - a link could open from that page. I wanted this test to work, even if I had set this as a manual check temporarily. And running the tests in debug mode made it easier to see any errors. I know pipelines for CI/CD can be finicky, and I didn't want any of my tests to cause problems.
I verified that the link would open correctly while doing a morning smoke test, and it did. The creation of this test was simple for most of it. I assumed that the link would simply open as it did when working in the usual environments, even with the Incognito browser that the test runner would use. Copying some of the test code from other tests in this series made sure the test would work for the basics, and just add this one small thing. With high hopes, I ran this single test of the series in headed mode, to make sure everything worked as it should. And the first run did something unexpected!
The browser happily opened and did all the things I needed it to do to get to the link I had to verify. Clicking the link brought up a surprise - a time out which I had not anticipated. Which meant figuring out what the code needed. Digging out my tester toolbox, I set to work.
Incognito browser, check. Successfully figuring out my password before I locked myself out of the system, check. Opening the page and clicking on the link, check.
A new tab opened - and a log in to a larger system was presented. I mentally reversed this: I should have suspected that this would happen -- the link lead to a site I use often, and it has a "remember to close all browser windows!" note once you log off. There was the problem - no, two or more, tackle one thing at a time. Getting Playwright to open a new page should be simple, I'd seen it in the documentation. Or I could use the tools that were there and try it with CodeGen - and get the correct answers to several of the issues at once.
A few minutes with CodeGen got me the basic things I needed (I certainly would not have considered the new tab a "popup")! I still had to enter my information and had links that I suspected would not repeat - but I had a lot more than I did. To make sure I had everything in the test, I copied and pasted it in - long links and all - then saved the file and committed the test to Git.
Enough for one day - I remembered to leave on a high note.
Back to it, after a morning of manual tests. I added the needed information to log in into the appSettings file (knowing that this would be replaced later with environment-specific information by the pipeline) and spent some time catching the specific pages that would load. This was just a matter of sitting down and finding the locators that would appear, and the need to add a wait to let the window fully load after the button was clicked. The first one was a slog to get it to finish waiting. For the next two I was able to mostly copy the line to repeat the wait time. Then the locator was visible, and the URL of the final page confirmed.
And then another error while running this in debug mode - some of you may suspect what it was. I had the system log off. The closing on the second page, however, caused an error.
System.ObjectDisposedException: Cannot access a disposed object.Now what? The context was right in front of me - why did Playwright think that it had been disposed? At work, we have a rule that you can work if you are stuck for 45 minutes, then you need to ask for help. I admit, I don't always follow this - I spent too much time needing to research why something was written in the documentation, and what was presumed to be known before starting for it to be of much use. After several tries and an upcoming meeting with Our Database Wizard - many other skills in his tools make him a popular target for asking questions. But since we were meeting anyways, I mentioned that I was having an issue, and he kindly agreed to look. Once we got the documentation figured out - the original purpose of the meeting, I brought up the IDE with the Playwright code on it and prepared to move the text as needed for him. After a few seconds of reading, I heard a happy "Oh!" from him. Playwright is written in async code - I knew this. I did not, however, realize that the window for logging into the larger system had already shut, behind the scenes. A few moments of explanation, commenting out the single line where that secondary page was going to be closed, and the test worked correctly. And it was a decent test, he agreed: this link had not worked at points in the past, so it did need a test for it. I learned a lot, and now plan some extra time to research what async code might do in the situation I'm going to be testing. I felt silly for not catching that myself. But one does need to learn, and having someone that will look at the code before it's ready is sometimes the best way to learn, as well as make the changes that are needed.