Hi everyone!
Well, I found some time to make a post here. On the ASP .Net project we're working on, things are going pretty well (although they have slowed a bit -- working on getting back into it). Still don't have my dev machine though.
Anyway, our previous work over the past two months has been mostly bug fixing, but we've recently implemented an actual new feature. The feature in question required some pretty substantial modification of various parts of the site and so the potential for breaking things was there.
Luckily, both our unit test suite and functional tests have grown pretty substantially and so there is a lot of coverage to ensure things don't break. In fact, the feature in question affects areas that happen to be heavily tested, so we can prevent regressions that way.
But it's not just about having test coverage of the code you're modifying -- you have to treat your test code right. That is to say, the test code is not "just test code" and it should be held to certain quality standards like your production code. We've spent a good chunk of our time establishing a test architecture when we could spend that time cranking out more badly written, fragile, hard to maintain tests.
Instead, we've taken the time to isolate potential changing parts of the code (such as element locaters) and build an abstraction layer on top of the Selenium API specific to our project. This makes the tests easier to maintain and less susceptible to UI changes. Another nice benefit is that it's reduced the time it takes to write functional tests like this substantially. Most of the actual Selenium code has already been written, and writing a test means creating different page objects and calling their methods.
When we do add to the page objects, it's usually a small amount of code and just means we'll be reusing it later.
So, the moral of this story: treat your tests right and you will benefit from it (we certainly have).
See you next time!
No comments:
Post a Comment