Testing in the Wild by Heather Williams

Introduction

This talk is aimed at anyone interested in testing real code with real deadlines. In this talk Test Driven Development (TDD) will be explored along with alternatives to TDD. By the end of this talk participants will have a greater understanding of how to apply one of the tools of testing in the real world and how to ensure they have time in the development cycle to test their code.

Questions covered

Almost everyone talks about TDD these days. TDD is taken as the thing to aim for and the one thing you must do as a developer. But does TDD actually work when you are out of the classroom context and in the real world? Are there alternatives to TDD that are better to use? How do you begin to test legacy code so that you can change it safely? What about that new feature that marketing wants ASAP and you have to quickly pull a rabbit out the hat for? How should one ensure that this new code is added rapidly but with good tests? These and many other questions will be briefly explored in this talk.

Tools used

This talk will focus on unit testing and will use Python nose as the test runner. Python nose extends unittest and makes it easier to setup, discover and run tests with Python. Some brief examples of tests will be shown using Python 2.7 but the broader concepts apply equally well to Python 3.

Transcript

1. Testing in the wild Heather Williams
2. Who am I and what do I do? I am a fullstack developer. I work for Siyavula Education building a practice service for maths and science high school learners. See the service in action: https://www.siyavula.com/
3. Introduction What is testing? In a nutshell it is a means of ensuring your code always works. Why testing in the wild? We are out of the classroom context and in the real world. Why are you picking on test driven development (TDD)? TDD is one of the hottest topics in testing.
4. Why test at all? Without testing things can go badly wrong • Planes flip upside down on crossing the equator • Ships stop dead in the water when crossing the international date line • Probes crash into planets • Customers get upset with you
5. Why test at all? On Thursday Bob from marketing says they need a new feature out on Monday. You work all weekend and give Bob a buggy feature on Monday. Not cool but sometimes the business needs are such that you have to code fast. As a developer you need to take the time to have some tests added in by whatever means necessary be it TDD or writing the tests after development. This means Bob gets a non buggy feature and everyone is happy.
6. Types of testing Many different types • Unit • Integration • Functional • System • Stress • Etc. We will focus on unit testing in this talk.
7. Testing methods • Test driven development (TDD) ◦ Test before writing code ◦ Focus on the tests and single units of code ◦ Written in programming language • Behaviour driven development (BDD) ◦ Extension of TDD ◦ Focus on behaviours ◦ Written in natural language, e.g. English
8. Testing methods • Tests follow development (TFD) ◦ Write the code then write the tests ◦ Focus on the code ◦ Written in programming language • Test driven refactoring (TDR) ◦ Write tests then refactor code ◦ Focus on what the code does ◦ Written in programming language
9. Unit tests Test just one unit of code on it’s own and see how that unit behaves.
10. Test driven development TDD is a software development method where you write the tests then you write the code. TDD is meant to be used with short development cycles. TDD is not new, it has been known in some form or another since the late 90’s. Recently it has received more attention due to its use with agile coding. https://softwareengineering.stackexchange.com/questions/41409/why-does-tdd-wo rk https://zeroturnaround.com/rebellabs/if-and-when-you-should-use-test-driven-devel opment/
11. Where does testing in general fail? • If there is no buy in for testing. ◦ The dev team has to accept that they need to write tests ◦ Management must accept that you might have less bells and whistles to make time for tests ◦ Clients must accept that extra time is needed to add tests • When you just throw some tests together ◦ Sometimes you have finished a project and are told to add tests so you throw in a few carelessly thought out tests
12. Where does TDD fail? TDD can fail when you try make it do more than just test a unit. There is a debate over whether or not you need well defined requirements. In general the fuzzier the requirements the harder it is to use TDD. Legacy code can also give you a lot of difficulties with TDD. Machine learning code is hard to test as is code that needs IO devices. Video game industry often does not use TDD
13. Writing and running tests the TDD way 1. Write a test 2. Run the test and see it fail 3. Write the code to make that test pass 4. Rinse and repeat until you have your feature
14. Real world examples - the good Case in point: writing a function to show how many users are active In this case the requirements are clear: a number between 0 and infinity is needed. You can write tests to take the information you have about how many users are active and return that information. Simple enough input. Simple output.
15. Real world examples - the good
16. Real world examples - the good
17. Real world examples - the good
18. Real world examples - the good
19. Real world examples - the good
20. Real world examples - the good
21. Real world examples - the fuzzy
22. Real world examples - the bad Testing the project module
23. Real world examples - the bad Need to set up a fake school, a fake class, a fake learner and some fake data for the learner. With so much to set up you stop testing what you think you are testing and start testing your ability to write fake data. Without using fake data you cannot test that a project returns the correct information (e.g. how many exercises were done).
24. Key takeaways • More to testing than TDD • Test your code to make good code not because you must • Question everything
25. Questions?