Slide 1

Slide 1 text

Testing in the wild Heather Williams

Slide 2

Slide 2 text

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/

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

Types of testing Many different types ● Unit ● Integration ● Functional ● System ● Stress ● Etc. We will focus on unit testing in this talk.

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Unit tests Test just one unit of code on it’s own and see how that unit behaves.

Slide 10

Slide 10 text

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/

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

Real world examples - the good

Slide 16

Slide 16 text

Real world examples - the good

Slide 17

Slide 17 text

Real world examples - the good

Slide 18

Slide 18 text

Real world examples - the good

Slide 19

Slide 19 text

Real world examples - the good

Slide 20

Slide 20 text

Real world examples - the good

Slide 21

Slide 21 text

Real world examples - the fuzzy

Slide 22

Slide 22 text

Real world examples - the bad Testing the project module

Slide 23

Slide 23 text

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).

Slide 24

Slide 24 text

Key takeaways ● More to testing than TDD ● Test your code to make good code not because you must ● Question everything

Slide 25

Slide 25 text

Questions?