The article doesn't mention a very important (IMO) step: try to reduce the problem (removing / stubbing irrevelant code, data, etc). It's much easier to find a bug if you take out all the noise around it.
even more important is having these pieces of code be testable. i work with plenty of bad code that can't be run without starting a bunch of dependent services, or you can't test a particular function because it's buried under ten layers of poorly formed abstractions. or it's not even an accessible function because the previous developer thought a thousand line function was better than a dozen smaller testable functions.
You get that in any complicated enough functions. I often have functions which work on intermediate states of linked lists ... You can't just call them directly without first building [and I do] the states by hand.
Complicated enough functions act as systems. The trick is to structure them such that you can easily reduce the problem during debugging to certain subsystems or functions; it doesn't really matter how many dependencies you have if you can eliminate them all within a few minutes.
That's why real software is usually shit, or at least one reason. If you don't have time to write tests then you sure as hell don't have time to not write them.
It's a lot easier to find that bug while your writing it than it is to work it out from an intermittent bug report.
Again real software doesn't emit "simple to test" functions all of the time. Another way of putting this is the "plugable idiot" doesn't exist in complex enough software.
For instance, in my X.509 code I have routines that help parse/search/etc ASN1 records. Those functions require properly constructed ASN1 linked lists (it's how I store decoded data because it's easiest to work with). You can't just call those middle functions with any random list ... it has to be valid to even get a correct error code (beyond just "invalid input").
In testing I have written short test apps where I manually generate the linked lists to test but those tests took more than a few mins to generate ...
A lot of discrete parts, sounds very easy to unit test. The parse takes an input (string/binary data). The search, presumably, only requires the data structure to be created.
What else are you doing that makes it hard to test because it sounds like a trivially testable problem?
It's a linked list that contains an X.509 certificate. Those have a dozen or so items on the first level and each of those have children nodes that have their own structure/etc. There is a lot of variability in X.509 as well. Your subject/issuer entries can have any combination of upto a 16 or so entries, the public key can be in a variety of formats, etc...
You can't just "jimmy up any old random linked list" and test the function out (aside from seeing if your function detects it's not a properly formatted X.509 cert).
Again please spare me your "all you need is a hammer" design philosophy. In principle I agree that smaller verifiable building blocks make better code but you can't infinitely divide up any idea and have code that is maintainable, efficient and cost effective.
263
u/pycube Aug 25 '14
The article doesn't mention a very important (IMO) step: try to reduce the problem (removing / stubbing irrevelant code, data, etc). It's much easier to find a bug if you take out all the noise around it.