Since seeing @Jeremy Cowgar 's presentation at XDC2016, I’ve been moving towards test-driven development. In short, write a test first, write/update the code until the test passes, refactor, repeat.
Yesterday, while writing a Dictionary subclass, this method saved me from putting work into code that, in the past, I would have written before realizing it was unnecessary. In short, I wanted to make sure the Constructor(ParamArray values() As Pair) worked as intended, but before overriding it, I wrote the test first. Imagine my surprise when the test passed because, it turns out, that form of the Constructor uses my overridden Value method.
I’m a believer. If you get a chance, look into TDD and check out excellent Jeremy’s presentation.
I have worked in environments that TDD was the norm. If everyone does it and you follow a sane programming process it works. If certain functions/methods get done based on “dictations from above” vs need or normal process then TDD can break down. Or at least in my experience.
I’ve always liked writing a huge chunk of the “user manual” before hand.
That way people can think about what it should look like, and what things should happen when you press this button or that one WITHOUT having to talk code.
That way you & your client know what to expect and its easy to change paper.
This methodology is essential in my primary coding arena, embedded, every single project MUST be a test driven system with a larger portion of debug-test-note typing written than actual running code, especially when having to use a compiler (the majority) where there is absolutely zero debugging, a bit like writing for Pi in Xojo!
But all good fun and certainly a whole load more learning done than that easy-peasy IDE debugging!
