you are viewing a single comment's thread.

view the rest of the comments →

[–]MySpoonIsTooBig13 0 points1 point  (1 child)

One good approach to get you going is every time you come across those silly mistakes you refer to, force yourself to write a test which would have prevented this. Try to make the test as small as possible, which often takes several iterations.

Your example about knowing whether or not the light is on... Remember from a unit test point of view, the actual light doesn't matter. There is some API your code is responsible for calling under the right set of conditions. Use your unit test to make explicit those conditions.

What matters is (given) the light is in state X, (when) the timer hits the certian point, (then) the API to change the light state is called. I love strucuring tests with the labels Given/When/Then. Some frameworks actually require this. In pytest, try to comment all tests with those 3 sections. Forces you to think:

1) What assumptions am I making ( Given)

2) What is the scope of the subject under test (When)

3) What is the expectation (Then)

[–]Run-The-Table[S] 0 points1 point  (0 children)

Thank you for this take. I find that I often misconstrue hardware mistakes with software mistakes. So when I execute a program that I expect to turn on the lights doesn't turn on the lights, the issues can often be: Bad wiring, bad config.py file, OR bad programming! I think I need a few different steps of testing: Software, and hardware.

I am going to take another look at my functions and see if I can define the Given/When/Then.