The document provides an overview of automated testing and test-driven development. It discusses why developers should write automated tests, different types of tests, tips for testing, popular testing tools, and an example of how test-driven development works. The document also shares a real-world example of how automated testing helped a company upgrade their PHP version and save $1 million by detecting errors early on. It concludes by encouraging readers to start writing tests and providing references for further information.

1. www.bsc.es Barcelona, 11th April 2016
Write tests, please
An automated tests overview
Joan López de la Franca
Computational Earth Sciences

2. 2
Agenda
Introduction
Why automated tests?
Tips & tricks
Tools & helpers
Test Driven Development
Real world example
Next steps
References

3. 3
You should write tests
First of all
– You should differentiate between QA team tests and software
developers tests
– Automated tests are also called developer tests, so..
– If you write lines of code..
You should write automated tests!
(Please, try to feel identified with it)

4. 4
Not only unitary
There are a lot of different kinds of automated tests
– Unit tests
– Integration tests
– GUI tests
– End-to-end test
– And so on..

5. 5
The origin..
eXtreme Programming (also named XP)
– Software development agile methodology
– Developed by Kent Beck (Agile Manifesto)
– Intended to improve the software quality
– Include some practices like:
• Pair programming
• Code reviews
• Unit testing
• And so on..

6. 6
..and the goal
What most teams have and what most teams should want
(TestPyramid)
Test suite on most teams Our goal
The lazy guy rule
Why spend a lot of time to do something that could be
done with few minutes?

7. 7
How they should be?
Minimum requirements of a test
– Automated (of course): without manual steps
– Complete (more coverage means more reliability)
– Independent (the order of the factors does not alter..)
– Repeatable (let me see, that it works)
– Well-named (test1, test2, test3 names are not allowed!)

8. 8
Their skeleton
Which parts compose a test?
AAA
– Arrangement: needed steps to prepare the test
– Action: what you want to test
– Assertion: check if everything works
Let’s see an example with Python!

9. 9
Simple example
Imagine that we have a Calculator class with a method sum
which is what we want to test
(Remember the AAA)
class TestCalculatorUnit(TestCase):
def test_that_two_plus_two_is_four(self):
# arrangement
my_calculator = Calculator()
# action
sum_result = my_calculator.sum(2, 2)
# assertion
self.assertEquals(4, sum_result)
A
A
A

10. 10
Why automated testing?
Benefits
– Helps us to make better designs (more changeability)
• Improves the productivity
– Allows us to be much bolder modifying the existing software
– Allows a more evolutionary software development
• Deliver early, deliver often!
• Speeds up user feedback
– Improves the software quality
– Are more repeatable than manual tests
• Provides more reliability
– Documents the code (easy way to know what the code does)

11. 11
Why automated testing?
– Implies less effort than manual tests
• More runs
– Earlier error detection
More productivity, less costs

12. www.bsc.es
Tips & tricks

13. 13
How to fix a bug?
“Our client has found a bug, fix it, please”
– When this happens, there are some typical questions:
• How to fix it?
• How to find it on the code?
• How to ensure that it won't reappear?
“You know, write tests”
• Make your test successfully passed
• Find why your test is not successfully passing
• If you never breaks the test, it never won't reappear

14. 14
How to deal the dependencies?
Making painless the dependencies maintenance
– We are in the 21st century
• Nobody writes entire systems
• Everybody have dependencies
– Updating dependencies is a painful process for most teams
• The updates may break your system
• You should update (security reasons)
– Write integration tests with your dependencies
• To be notified if something is broken by an update

15. 15
Why are you writing on disk to test?
– Do you remember the last ‘Calculator’ test?
– Now imagine that we want to write to our log ‘high result’ when the
result of the sum is higher than 10.
How do you test this?
–No, the answer is not precisely check if there is a ‘high result’ mark
on the log file
– You will find the right answer on the next section
– SPOILER: You should test only your code.
» Not the native ‘open’ or ‘write’ calls.

16. www.bsc.es
Tools & helpers

17. 17
Fakes, mocks, stubs and spies
Helpers to simulate the reality
– Classes, libraries or modules
– Different types with different proposals:
• Return fake values
• Check return values
• Check method calls
– Times
– Arguments
– Exists one for most programming languages
• Mockito
• Some languages have included it natively (Python)

18. 18
Mocks example: autosubmit
Mocking the reading of the configuration
class TestAutosubmitConfigUnit(TestCase):
def test_get_property_returns_the_right_value(self):
open_mock = mock_open(read_data=“PROPERTY = value”)
with patch.object(builtins, “open”, open_mock):
obtained_value = AutosubmitConfig.getPropertyValue(“PROPERTY”)
self.assertEquals(value, obtained_value)

19. 19
XUnit frameworks
Testing tools
– Family name given to bunch of testing frameworks
– Originally from JUnit (first widely known)
– Provides a complete API
– Exists one for most programming languages
• Some languages have included it natively (Python)

20. 20
Coverage
Code Coverage
– Simply a measure
– Different types
– How much code tested by a suite
– Some benefits (unit testing):
• Dead code locator
• Error locator (unexpected behavior)
• Reliability unit of our tests
– Very used (see on GitHub open source projects)

21. www.bsc.es
Test Driven Development

22. 22
Test Driven Development
Aka TDD
– Focusing your development on tests
– Originally from XP
– Defines two main practices (very important!):
• Writing first the automated tests (before code)
– Think about: design, API, needs, …
• Refactoring the code
– Improving it: maintainable, reusable, reliable

23. 23
Test Driven Development (aka TDD)
Lifecycle

24. 24
Test Driven Development (aka TDD)
Benefits
– Leads to modular development
• Reusability
– Forces you to think before write code
– Helps to make quality designs (SOLID)
– Leads to develop exactly what is needed
– Helps develop new features without breaking nothing
– Helps document the work for the next day
– Helps reduce the number of bugs introduced during the development
process

25. 25
Test Driven Development (aka TDD)
Example
– Requirements
• Develop a StringCalculator that can sum numbers
• The sum method can take 0, 1 or 2 numbers
• The result can be 0, the taken number or the sum
• Only base-10 representation allowed
“Don’t forget it! First tests”

26. 26
Test Driven Development (aka TDD)
“Let’s write tests”
class TestStringCalculatorUnit(TestCase):
def test_fails_when_takes_more_than_three_numbers(self):
with self.assertRaises(TooMuchArguments):
StringCalculator.sum(‘3’,’5’,’1’)
def test_normal_sum_with_two_numbers(self):
sum_result = StringCalculator.sum(‘1’,’11’)
self.assertEquals(12, sum_result)
def test_sum_with_one_number_returns_it(self):
sum_result = StringCalculator.sum(‘999’)
self.assertEquals(999, sum_result)
def test_sum_without_parameters_returns_zero(self):
sum_result = StringCalculator.sum()
self.assertEquals(0, sum_result)

27. 27
Test Driven Development (aka TDD)
class StringCalculator:
@staticmethod
def sum(*args):
if len(args) > 2:
raise TooMuchArguments
elif len(args) == 2:
return int(args[0]) + int(args[1])
elif len(args) == 1:
return int(args[0])
else:
return 0
“Tests are failing. Let’s write code”

28. www.bsc.es
Real World Example

29. 29
Real world example: context
Badoo: dating social network
– Complex web application
– More than 200 millions registered users
– A lot of sensible data

30. 30
Real world example: situation
Do you wanna save $1 million?
– New PHP release is available: PHP7
– Performance improvement lets us to save money
• Less infrastructure needed
– Will all work after the upgrade?

31. 31
Real world example: problem
Nobody says that it will be easy
– Apart from the work that implies the upgrade..
– After upgrade you have hard work
• If you publish with a lot of errors then you will lose a lot of money
• You must test if all the functionalities with all the possibilities are still
working as expected
• How much time do you need?

32. 32
Real world example: succeeded
Finally they’ve done: $1 million saved
– More than 60,000 automated tests
– A lot of errors detected
– Easy problem detection
– Quick way to ensure that system works

33. www.bsc.es
Next steps

34. 34
Application on the Department
I hope so
– Next time you go to write code..
• Write first a test
(It's an effort that everybody should do)
– Ask me if you need help to start

35. 35
Application on the Department
Future sessions
– Make your suggestions
• Specific technology
• Specific problem
– Coding Dojos

36. 36
References
http://www.martinfowler.com/
https://techblog.badoo.com/
http://googletesting.blogspot.com.es/
https://docs.python.org/dev/library/unittest.html
http://xunitpatterns.com/

37. www.bsc.es
For further information please contact
joan.lopez@bsc.es
Thank you!