TDD Rules in Any Language
November 20, 2016
I’m working on a very complex problem on my master’s class, it deals with structural approaches to apply the bat metaheuristic on GPU. Beyond this big challenge, I wasnt used anymore to C development. The last time I made something for real with C was about 3 years ago and back then I had little experience, for that, I started this challenge with little confidence.
Soon in the process I felt some mistrust of the behavior of the code. And as complexity increases this mistrust did as well. And when unexpected results appeared I started to became crazy and did a lot of suffered debug. Maybe there are some overwrite of memory biasing the values? Maybe there’s something I don’t understand happening with the random numbers?
The thing is, when you have too much complexity is to easy to don’t feel confident about your code. I suffered a lot for one week or two until I embraced unit tests on C. Sure, I should had embraced TDD since the beginning, but as I said, I didn’t had the confidence to do it. Here that maximum applies: the developer don’t take the time to go fast.
Anyway, it seems that it’s not at all that common, TDD on C, the most starred library I found was Unity, and it has about 0.3k likes. But certainly the major benefits of unit testing apply for as as much as for any other language. I even feel inclined to say that C is a perfect language for testing, since you’re forced to define contracts on header files and include the “concrete” one’s at compile time (ideal for mocking), it’s a kind of forced dependency inversion that the language design enforce.
But in resume, now I’m much more confident of the behavior of my algorithm. I can say to my advisor, with confidence, that the behavior is expected given the premises.
And, as a bonus, I found a bug on Unity and sent them a pull request which is already merged.