I’m just starting to get to grips with TDD, and I have 2 quick questions;
I’m assuming that if I were writing software for a software company, that TDD would work alongside the software design? i.e all the UML, ERD diagrams, flow diagrams etc…
My second question is, the way I’m doing my tests at the minute, I think about what will be called in the code (e.g a method) and I think about all the possible erroneous inputs and correct inputs. So for example, lets assume I know I need to call a “loadfile”, so I write just enough code to make the test pass…
But then I also start thinking about, what if you don’t specify a parameter, or an invalid file, so I write a few more tests to test for exceptions – which then involves adding a bit of logic into the method (so the correct exception is returned)
Is this the correct approach to TDD?
TDD is primarily an implementation technique, so it works as orthogonal as writing other code to the “graphical” design techniques you mentioned. (If the latter techniques are used in all software companies, for all kind of professional software, is a completely different question.) When you have UML diagrams on the abstraction level of your public class API, with method signatures, then feedback from the implementation level, or maybe from coded tests can influence parts of your public class API and so influence your UML models, but that is always the case, if your are doing TDD or not.
If I understand your 2nd question correctly, you are talking about small cycles of writing tests, implementing, extending the tests, extending the implemented methods to fulfill the new tests? Actually, that is exactly how TDD ideally should be done “by the book”.
In fact, there are some (IMHO wrong) myths around that TDD is about writing “all tests first”. I think that is a misunderstanding: TDD is about writing ideally only one test at a time, then implement a little, write the next one test, and so on.