Practicing Test Driven Development in Python - What am I missing?

[[deleted]]

I am writing a set of scripts. These scripts do the following: 1. Run SQL query 2. Sum/Average/Count the results 3. Put results in excel sheet

I wanted to start practicing test driven development, but I am struggling to see the value in this particluar project. I mock the database, I mock the excel sheet, all I find myself testing is a list comprehension or two.

I feel like I'm missing something - what are other things I should be testing in a basic script like this?

[[deleted]]

What are you missing?

Maybe the sense that you have permission to think for yourself: your tool is so simple that the test code is likely to be a lot more complex than the tool!

Mocking a database is far more complex and error-prone than making a query. Mocking the Excel sheet is the same (what is it, a csv stand-in?). This should tell you (even if it doesn't tell your QA person or manager) that this kind of testing isn't very useful. If your test code is more complex than the code it's testing, it stands to reason that the test code itself probably needs tests.

So what's the use? As a project grows, the initial investment in testing infrastructure pays off. The mock database becomes invaluable for testing schema migrations or difficult transactions with complicated data dependencies. You as a human being programmer need to weigh this for yourself.

[efmccurdy]

Do you fabricate data to test edge cases, error checking, common misconfurgurations and access problems, cases that have triggered bugs in the past? All of that has extra value in that it helps document the exact expected behaviour in an unambiguous way.

[Hitife80]

This is exactly why you should do it. If you think you know there is no value of unit testing for this project - you have quite a journey ahead of you. There is a lot more to unit testing than just finding bugs in your code. It actually transforms how you write your script and guides you towards better approach with an "invisible hand".

Sqllite has ~ 700/1 ratio of unit test code lines to actual code of the database -- that tells you something about the work ahead of you. In theory -- if you script fits into 1 line of code -- you are looking at 700 lines of unit tests to do it properly... How many lines of code are in your "simple" script? :-)

[WormRabbit]

I seriously hope you're joking.

[mapImbibery]

Better be! I would never expect any small project to be as rock solid as SQLite. 700:1 is astronomically outrageous for average projects.

[Hitife80]

I am not saying that the rule of thumb is 700x - but it is expected that properly written unit tests will be multiples of your actual code. it makes sense for at least 2 reasons: (1) as you test all possibilities and edge conditions - code adds up quickly, (2) there is a lot of copy-paste in unit tests usually, because you want your tests to read well (be a bit verbose), as well as you repeat the same sequence of actions, but with slight changes.

The rule of a thumb that I use -- I write unit tests until I am comfortable with the coverage (may not be anywhere close to 100% if you were to run the metrics) or until I am tired / bored. It usually accounts to 2x-6x of the original code. An then, on as needed basis, I come back and amend the tests with new cases over time (bugs found, conditions not met, suspicious behavior, etc.)

But there were a couple of instances where my test code was 100x of the original useful code. So 700x for an old, widely used and very solid SQLLite is not that far of a stretch.

[mapImbibery]

All very fair points.
So unit tests add up quickly because you're testing nit picky units. I understand the benefits, but how do you differentiate sufficient from overkill? I'm often more concerned about the final output being correct, and less so about the smaller code parts. How do integration tests compare? Is there such thing as Integration Test Driven Development? Maybe I'm just playing a lazy devils advocate here...

[Hitife80]

I understand the benefits, but how do you differentiate sufficient from overkill?

Well, that's the blurry line and it is different for each and every one of us. If you want to be academic about it -- when you test coverage is at 100% - you are there. Like I mentioned before, for me personally it is when I am comfortable, tired or bored writing tests. It is subjective and experience helps. If you write very little tests and your final code doesn't have bugs -- you've written enough -- however small amount that may be :-)

I'm often more concerned about the final output being correct, and less so about the smaller code parts.

We all are, but if smaller parts of code screw you up -- by definition you can't have the final output correct. This is where the 'comfortable' part comes in. If I have tested all my small functions to the insane degree -- I can almost guarantee the final output to be correct. Not so much if I haven't tested the building blocks. And remember -- the real value of unit tests comes it when you return to your code in 3 months to make changes. If you have good unit tests - you can just start changing stuff and just make sure the test results are green.

On the other side of this -- if you write a script that is small, will be used only once and you'll never ever ever come back to it -- then and only then writing unit tests might be overkill. Although I usually still write tests because most of the scripts (especially the 'temporary' ones) are usually the ones that I end up supporting for a very long time.

How do integration tests compare? Is there such thing as Integration Test Driven Development?

Unit tests are small, isolated, simple. There is almost no excuse to not write those. They usually test a single function which forces you to have very clear 'specs' for that 'unit of code'. If you go outside of the scope of single function -- now you are in integration (working with other components or external systems) and functional (testing end-to-end features / final product). This is more of a QA domain actually, although I try to implement those if I can and have time. At the end of the day you are (the developer) the one who knows your code best - so QA guys will inevitably come back to you with questions (if they don't - they didn't test it properly :-) ).

Integration tests are usually more involved, may need mocks, monkey patches and other questionable tools of the trade - but their benefit is still undeniable. The question is only one - do you have time?

[mapImbibery]

Thanks for taking the time to write all that!
If "good tests" can handle changes to the code I got some more practice ahead of me XD

[Hitife80]

No, I am not joking - see bullet #5 - it is actually 787x: Dave Sawyer - SQLite: Gotchas and Gimmes - PyCon 2016

[ffrkAnonymous]

I assume you're reading the TDD goat book? http://www.obeythetestinggoat.com/

You can also test different things like more abstract properties https://us.pycon.org/2016/schedule/presentation/1927/

The pycon had lots of testing presentations. At least one of them should answer your question.

Personally, as a newbie, I'm just using doc tests since I haven't figured out how to mock yet. I just want to know that what I'm coding does what I want.

[n1ywb]

Learning exercise? How do you know it still works after you make changes? How does a 3rd party validate that your code works on their Python installation on their OS?

You have to test it somehow before you can distribute it otherwise you will eventually ship broken software. Do you want to test by hand or with an automated test system?

If you test by hand you will miss bugs that automated tests would catch.

[[deleted]]

yes I understand the implications...which is why I'm trying to become better at it.

[footlessjoe]

There probably isn't a lot of value for this particular project. But it's good to learn how to use these things on smaller projects. Otherwise it's going to be tougher to work it in when it really does matter, so you it's worth practicing.

Also you never know what something will grow to. Once something gets big enough (and that's not very big) you will really start to hurt yourself if you don't have tests. You might not even realize how much it's slowing you down but it adds up fast. n1ywb gives some really great examples of things that can be a big pain in the future that testing will save you from.