Friday, January 4, 2019

Email: Changes to Automation That Fix TestA but Break TestB

Summary

As our Selenium automation team grew, it began to feel like we might be fighting with each other over element locators and library methods.  To try to avoid this, I recommended we look at git annotations while making these little code changes.

--------------------------------------------------------------------------

Team,
I was just going to send this to Andy and Victor, but it might be useful to more of us as more people contribute to the same codebase.  Hopefully this will be a helpful strategy to prevent us from breaking one test while fixing another.

This came to mind when I saw Victor's comment on a pull request:

Victor said "I will check all occurrences again."  This could take a lot of time, and sometimes it will be very difficult to even determine all the tests that use a certain library method or page element.


These little changes are at the front of our minds in OMS since we're going to be executing and re-executing over and over, trying to get tests to run consistently, fixing the little things that are breaking our tests.  In the example above, if 2 tests use the page element that Victor is changing, it's very possible that the locator is actually different in the scenarios in those 2 tests.  I think a good way to avoid fixing testA but breaking testB is to view Annotations in IntelliJ.  Just right-click in the gutter between the line numbers and the code area and choose Annotate:

If I were changing one of these page elements that was last updated several months ago, I would feel pretty confident that my change wasn't going to break any other tests.  But if the last changed date was a couple weeks ago, then I should ask that person, or just look at that commit.  IntelliJ makes that very easy too – just right click on the date or the person's name and choose Show Diff:

If you want to see their git commit message (this is why we write good commit messages!), you can just hover over the date or person's name, or from the menu above, select Select in Git Log.

This won't work all the time, but it should keep us from thrashing – where one person fixes testA, breaking testB, and then someone else fixes testB, breaking testA.

If anyone else has bright ideas on this, feel free to share them here...

No comments:

Post a Comment