it('should be easy');
Paqui Calabria @zurribulle
Survey
Age
What do we think about automated testing?
"The best way to have a maintainable code"
"They add quality. It's easier to refactor or add/remove features"
"Very useful, and save time in the medium-long term"
"They rule! I prefer automated tests so I don't need to speak with QA"
"Required to ensure a good enough design"
"They are required, but you don't have to have them just for the shake of it"
Do we do enough tests?
Why?
Really?
You don't drop a good tool because you don't have the time
| Step | No tests | With tests |
|---|---|---|
| Implement | 7 days | 14 days |
| Integration | 7 days | 2 days |
| Testing & debug | 12 days | 9 days |
| Total | 26 days | 24 days |
| Bugs in prod | 71 | 11 |
The art of unit testing, Roy Osherove
Automated tests doesn't look so productive because we do not take full advantage of them
Lack of theoretical knowledge and good practices
"Testing standars are difficult to find"
"Automated tests can be hard. I think a good share comes from using the tools incorrectly"
"It's hard to determine how, where and what to test"
10 + 1 tips to improve your tests
Each test must be independent
If you need a test to pass to run another, you'll be creating false negatives.
If there is a lot of set up, use beforeEach, helpers, page objects...
Sort tests from general to specific
When several tests fail, you'll know that you need to start debugging for the first one.
Check one thing per test
It's ok to use more than one expect, but if the title says "and" it will probably end up being hard to maintain
Don't forget to clean up
Any modification to the environment that a test has made, has to be reverted later to avoid collateral effects.
Delete local storage, reset the database, restore the stubs/spies' behaviour...
Make a mocks' library
Mocking is boring, slow and repetitive. Create a library of mocked objects, services, components, etc that you can access from any test.
Asynchronisms are going to fuck you. Big time
Learn to control them as soon as possible, study, practice.
https://blog.cloudboost.io/javascript-asynchronous-testing-gotchas-ac7e5c39257
Don't let them "expire"
Do the tests as soon as possible, run them often, and fix them as soon as they fail.
You can use CI tools like Jenkins or Travis, git hooks...
no tests = no merge.
Do not obsess about the coverage
The full report is useful to know what we are leaving untested, but in the end it is just a number
https://github.com/FCalabria/coverage_is_a_lie
Do not test trivialities
It is badly invested time, and it increases the maintenance cost.
There's life beyond UT
Study the weaknesses of the project before blindly implanting unit tests. Another type could be more useful.
Set a time limit
Desperate situations require desperate measures. It is also a good argument to convince managers.
Automated testing for non-developers
A.k.a how to explain your boss and not end up sending your resume
Nobody is born an expert
Why?
Easier refactors
Better understanding of the requirements
More robust components
Decreases the bug resolution time
Docs for other developers
CD with fewer bugs
We already have a QA guy
Automated and manual testing are not exclusive
When we use automated testing, testers can invest more time checking new features, accessibility, customer requirements, etc.
Does it takes longer?
Development time seems longer, but in the long run it is reduced because there will be fewer bugs and it will be more maintainable.
I want numbers
Realizing quality improvement through test driven development: Between 60 and 90% better code (number of defects), from 15 to 30% more development time.
Study your project's ticket tool, and mark which bugs could have been avoided with automated testing.
It's a big risk
Propose to do it only for a period of time and then analyze the results.
Another option, apply it only in a certain part of the project that can be problematic and will give more benefit.
If nothing can convince them, do it anyway
Add the extra time for testing on the planning
Save statistics for later:
- Potential bugs catched by tests
- Bugs reported with / without tests
- Bug resolution time
- Time invested modifying features