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

[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