Write tests, please
Download as PPTX, PDF1 like222 views
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.
![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”](https://image.slidesharecdn.com/writetestsplease-160623062741/85/Write-tests-please-27-320.jpg)
Write tests, please
- 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
- 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.
- 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)
- 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”
- 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
- 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
- 37. www.bsc.es For further information please contact joan.lopez@bsc.es Thank you!