it('should be easy');

Paqui Calabria @zurribulle



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?



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.

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

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


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