testing101.md

title
Testing 101

So far you've been writing your programs amd running them time and time again doing that. A constant cycle of change-run-repeat until it works.

Which works fine until

• you have hundreds of scenarios and inputs
• the program takes quite long to run and it starts eating up too much time
• you accidently break your program and don't even realize (billions lost, rockets dailing, people dying)
• you get annoyed

Programmers are smart, and they are lazy. A powerful combination. They automated it helping all those problems above.

This is a complex topic with entire professions ans teams dedicated to this, but even knowing the basics go quite a far way and willfeel unnatural at first but as time goes by will feel quite natural. Also considering the very low standards on testing companies and open source projects just knowing the partfrom this chapter will make you a much betyer programmer.

assert

The basis of testing is generally comparing what value should be versus what the programreturns. We do this via assert.

>>> sum([1, 2]) # this is a builtin function
3
>>> assert sum([1, 2]) == 3
>>> # if there is no output means everything was fine
>>> assert sum([1, 2]) == 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

The entire principle of an assert is checking the condition and complaining if things are not right. Look at the code above and try to figure this out on your own.

assert sum([1, 2]) == 3

Try to think of this like a special if statement. Just like if statements you give it some conditon that gives a boolean (either trie or false) and based on that it varies on how it acts. So when the condition above is true then it moves on and if it's false it gives an AssertionError

Why not use if conditions

(Actual student question)

I did mention above that these are like a special type of if condition. So it is actually possible to get something similar with if conditions. The reasons not to do this are:

• The syntax gets clunky - additional indentation and lots of ifs floating around.

• The assert syntax lets you use test runners which will show you helpful messages like number of tests passed vs number of tests failed.

assert with messages

Red-green-refactor

Test runners

Now raw asserts are nice but they are also quite limited. For which we have test runnerswhich provide a better way to run test cases.

• Failure of multiple asserts reports each individually.
• Counting of fail and pass tests
• Easier syntax for more complex features.

unittest

pytest

Fancier asserts

You might also encounter other types of asserts like assertEqual, assertFalse, assertIn etc. They are just easier syntax (often programmers will use the term syntax sugar). You can just use simple asserts for most part and others when you are more comfortable with them.

Separating test files

So far we were writing everything in one file which is quite okay for small programs, exercises etc. More often it is kept in seperate files. This is quite easy to do and some frameworks will even do it for you.

Usually it will be either called something like test.py or tests.py. If there is a large amount of tests then it will be in a folder called test/ or tests/

Exercises

See Also

Reading

Oh I actually made a completed version of this. I had written this much on a flight and saved it. https://agitated-haibt-97e13c.netlify.app/2019/07/06/testing-101.html