Doing test automation is about writing code. Test automation code can be easily treated as second-class citizen. As it's not delivered to customer,...
For further actions, you may consider blocking this person and/or reporting abuse
👍 to all of this.
I find it ridiculous that there are still people in this day and age that reject the idea that test code is still code, and should be treated the same WRT functionality, performance, consistency, maintainability, readability...I'm probably still missing a few.
The term I came up with to try to drive this home to new hires/co-ops is TRIMFAT.
Targeted
Reliable
Intelligable
Maintainable
Fast
Automated
Tests
The only thing I think is not explicitly spelled out in your post is around making sure your tests are easy to deal with when your tests do the thing they were designed for - finding a failure. Most of the time the cost of a test is not the time it takes to write but the time it takes to figure what went wrong when it failed.
If I see something like the following in a PR these days I'll flip the metaphorical table 😡
What was the value? What was it supposed to be? What was the test trying to do in the first place? 🤬🤬🤬
As part of this, it's important not to just have assertions of the various things you are testing but also to validate the tests assumptions along the way. Even if your Assert was good (specified expected and actual, had an actual message with context, etc) maybe the root cause of problem was with a dependency the test had, rather than the functionality the test was designed for. When you have to investigate 47 failures from a test suite run of 2500 E2E tests, only 6 of which are from specific functionally tests, it sure would be nice if the output of the rest made it clear that the assumptions they were based upon had been broken.
Thanks for feedback. Very good point on assertions, when you have large amount of tests to maintain and investigate you want to have precise and detailed information about failures. Really liking the TRIMFAT shorthand.
Hi ,
Can you please give example of best practices on assertions and my be some examples for example if i want to test if a create account is allowed for this user i would create a function boolean canCreateAccount(){ return buttonCreate.isEnabled()}
Then I would assertTrue(canCreateAccount),,, can you please help in providing tips and advice to my approach???
Great examples and points Juho. I have found and seen many like this and resolving each of these scenarios does make a world of difference in the long run (efficiency, quality, maintainability).
Additional areas that I see also teams/testers lacking awareness in that contribute to bad practices/poor knowledge are:
Hi Alexander,
Great points about version control, do you have any article/link the can help me??
Thanks
Some great advice here, I'll be showing it to the team.