|
by Fullofkittens 03/04/2015, 5:54pm PST |
|
 |
|
 |
|
Ice Cream Jonsey wrote:
I'm using the Selenium Webdriver as Junits to bang against a server and automate stuff. Most of my code IS Junits, with @Test sitting there and everything.
I've got some classes most easily described as utility classes. And I want to get both myself and my team used to code coverage. Yes it is a little silly to have Junits for the automation, but not really if you could see the code.
I'm thinking of doing a kind of integration test for these utility classes. Like, an HTML5 page with one of everything we can do in HTML5. Radio buttons, drop downs, blinking text, the works. I could then ensure that my utilities return what I expect when they bang against this simple page.
I feel I am missing something obvious however, so I thought I'd go to Caltrops for help or abuse. Well, I came for the help and I'll stay for the abuse. Anyway, how would you guys accomplish what I've described?
ICJ
As with any automation project, you have to weigh the cost of doing it against the value that you'd get out of it.
From the little I know about it, this project - which, if I'm imagining it right, is a set of webpages that serve as examples exercising how your utility classes work and that they do work.
This project could provide your project with the following benefits (there could be more I'm not thinking of):
Regression safety for your helper classes
I don't think this project is worth it for the purposes of regression safety. The reason: you are already using these helper classes against your production code, and if somebody comes in and borks up a utility class, you'll know it because your tests will fail. Now, there's always the moment where you have to figure out whether the test is failing because of the SUT actually being busted or because the test is janky, but if you are using these helper classes presumably they are being used more than once so you'd still probably know right away. Not worth it IMO.
Teaching people about code coverage
I feel like this is, like, something to spend a half-day workshop on, not a reason to keep a persistent automation project running. Once the thing exists, no one is going to go back and think about whether it provides good code coverage to your test utilities.
Onboarding for new users of the test utilities
This might be worth it if you design & scope the project with this goal in mind. When people write tests it's super common to duplicate test code because they don't know what helper classes are available. If these test pages existed then you could design them in such a way that it told people where to look for the utility. That might be valuable enough to go ahead with it.
P.S. If your helper classes are complex enough that they need automated checks of their own, it might be time to bust those guys into simpler, more focused classes(?). I wrote an article a while back re: my opinions on how to structure abstractions in a UI test suite, this is the code from it (in C#) if you think you'd find it useful. |
|
 |
|
 |
|
|
|