Ok, I've been busy, busy, busy getting up to speed on a new project with new team members and it's just taken so much of my time. That's the lame excuse for not posting on over 2 weeks out of the way.
I thought I would share with you some notes I took when recently viewing a Webinar entitled "Maintaining Automated Acceptance Tests". A lot of it was quite general so I only really kept one eye on it, and I couldn't hear what was being said as I had no earphones with me. What was shown was good but I already knew most of it. However, I did jot down some useful notes which I am sharing with you now. These are my own words extrapolated from some of the webinar bullet points I saw on my monitor. I believe there is something in here for everyone in an Agile team, not just testers.
Declarative vs. Imperative
- Writing declarative statements is much better than imperative e.g. “login as administrator” instead of
[Select “administrator” from the user dropdown, type “XYZ” into the password text box, check the “stay logged in” checkbox, Click the “login” button]
- Declarative = Intent (what), Imperative = Implementation (how), avoid statements that describe implementation, which may change but intent stays the same
- Imperative tests are higher maintenance, and actual implementation may differ from what is stated (in a User Story)
- Applies as much to User Stories as automated tests: http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html
- User Stories can be written in a way that drives the automated tests using the same domain specific language (DSL)/business speak e.g. http://specflow.org/home.aspx
Automated Test Code Design
- Keep the code close to the intent, don’t abstract it too many layers away (higher maintenance)
- Lots of small methods (not public) with larger public fixtures that use those methods (tests use the exposed fixtures, not the hidden methods)
- Fixtures are declarative and describe common system functions in business terms
- Methods are imperative and describe granular functions in terms of implementation
- Helper methods are only for tasks that are not semantically meaningful to a test
- Test independence applies the same as in the manual test case world
- A test should not rely on other tests to put the system into the correct state, instead invest in quick setups & teardowns
- TIP: DB updates are quicker than creates when injecting/setting up test data
No comments:
Post a Comment