When used properly, the TDD development cycle in one of the most effective ways to improve the efficiency of a team and overall code quality. However, most of the time, misuse of this powerful technique brings unsatisfactory results. During this talk we’ll explore how to identify “testing smells” and how to prevent bad tests that negatively impact the design and architecture of a web app. We’ll investigate some real world mobile app examples in Javascript, Swift, and Java for Android that threaten to eat us alive!
7. @giorgionatili #mobiletea 7
!
Setup and Teardown
Tests clarity and readability
Mocking data
Contract tests
Behaviors driven development
End to end testing
The goals of testing
What we’ll talk about
8. “We are going to cycle in good and bad practices
highlighting potential solutions…”
How we’ll talk about this
11. @giorgionatili #mobiletea 11
Avoid the “Red” in Process
Test-Driven Development is not the one
true programming methodology, testing
is a tool for helping you!!!
20. @giorgionatili #mobiletea 20
Eventually decouple setups
Just in case you really need
complicated setups decouple them from
tests and include them in the setup…
22. @giorgionatili #mobiletea 22
Test the fundamentals
If you are not 100% test covered you
are not a bad person! Code coverage is
just about the quantity, not the quality!
27. @giorgionatili #mobiletea 27
Tests are code, treat them well
Write small, readable and decoupled
tests. Tests are part of your code base,
don’t write garbage code!
30. @giorgionatili #mobiletea 30
Iterative Testing
Writing all the tests first is a mistake
because you cannot have a complete
understanding of a feature from a user
story
38. @giorgionatili #mobiletea 38
Respect the privacy
Don’t expose methods just because you
have to test it: well-designed public
methods should use them in such a way
they don’t need be directly tested
41. @giorgionatili #mobiletea 41
Edge Cases and Code
Don’t start with edge cases (empty
string, null parameter) or error cases,
this has to happen in code!
42. @giorgionatili #mobiletea 42
Tests the Behavior
A test must validate a behavior, not an
input otherwise they don’t deliver any
business value, nor do validate the
product owner’s assumptions
51. @giorgionatili #mobiletea 51
Poor descriptions
Tests descriptions are one of the best
sources of documentation, never ignore
the importance of providing a good
description
53. @giorgionatili #mobiletea 53
Arrange, Act, Assert (AAA)
Separate what is going to be tested
from the setups and keep the
verification steps clearly identified
55. @giorgionatili #mobiletea 55
Avoid conditional behaviors
If you start to add conditionals to
determine if your code is executed by
the tests suites, it means that you are in
danger
61. @giorgionatili #mobiletea 61
Network Responses
Applications rely on external data
sources, it’s important to have clear
expectations about external APIs
responses
65. @giorgionatili #mobiletea 65
'use strict';
var supertest = require('supertest-as-promised');
var request = supertest('https://ngcourse.herokuapp.com');
var assert = require('chai').assert;
describe('Backend API', function() {
it ('should return the list of users', function() {
return request.get('/api/v1/users')
.expect(200);
});
});
Contract Tests in Practice
70. @giorgionatili #mobiletea 70
Divide tests logically
Never violate the Single Responsibility
Principle neither when writing tests,
keep them ordered and in a good
shape is the key to get the more value
from them…
71. @giorgionatili #mobiletea 71
Measure complexity
If you are not able to organize your
tests in such a way it means that you
are dealing with confusing (and poor!)
requirements
72. @giorgionatili #mobiletea 72
Scenarios -> Use Cases -> Behaviors
This connection is the key to defining
tests that clearly describe a feature and
its acceptance criteria
74. @giorgionatili #mobiletea 74
Test for pixels
Don’t use e2e tests for testing layout
implementations, automate (eventually)
screenshots and then examine them
75. @giorgionatili #mobiletea 75
Counting elements
Don’t use e2e testing to count UI
elements, use them to describe how the
UI *should change* with a specific
behavior
76. @giorgionatili #mobiletea 76
Writing E2E tests
Never wait too much, start to write end
user tests as soon as the requirements
are ready, the lack of automation can
bring to not reliable outputs
81. @giorgionatili #mobiletea 81
Common understanding
Don’t separate developers and testers!
Keeping them together allows you to
have testers that understand the app
internals
84. @giorgionatili #mobiletea 84
Preconditions
If you cannot define preconditions you
cannot write tests of good quality,
potentially there is a big
misunderstanding about requirements