I've made a couple of posts about D and there is actually a common theme. My case for D goes beyond a static scripting language. If you read my covariance article what you see is a technique to getting more out of static typing.
But D does not stop there, it provide arbitrary compile time execution of code. It has expanded in how much of the language is accessible at compile time with specific limitations on system calls (disk access).
There has been some very nice utility to compile time libraries like pegged and regular expressions. But this facility can also be used to write static unit tests. Now as cool as that sounds how do I explain how different this is from a unit test library that validates after compiling.
This is tricky because D facilitates verification in a number of different ways. Unit test blocks are built to the language, in and out contracts, class inveriants. When you consider all the places and features covered in the language have additional times to execute and stop a build the better.
I don't believe TDD produces good design, I practice DRCT (Design by Runs at Compile Time).
Top comments (5)
TDD makes sure you do not make basic errors in your code and catch faulty design quickly. It asserts calculations and conditions are done properly.
Static typing makes sure you put the pieces where they belong.
Both of these are complementary.
I don't think I tried to claim static typing promotes design, only that TDD does not produce good design and I recommend DRCT for better design.
Well it is not TDD's responsibility to produce design at all, but to verify if your design is sensible and actually does what you want. It is a part of good design, as is static typing, so I am not quite sure why you would promote one over the other.
Or maybe I am just misunderstanding what you mean by DRCT? Could you please elaborate?
I agree that TDD has no responsibility for design. Yet you use phrases like "verify if your design is sensible" and "catch faulty design quickly" these to me sound like responsibility and the exact things I mean it doesn't do when I say produce.
Software Design Through TDD
Jesse Phillips
I understand the confusion, since we are talking about a thing that is not just one component.
Saying TDD produces good design is incorrect - it is just a technique you can use to quickly get feedback on the design decisions you have made. Can you make these decisions without it? Yes. Is it easier to do so with it? Personally I would say so. Is it enough to achieve that? Definitely not.
As much as I agree that static typing is great and we could use even more ways of validating code before you even compile it, I cannot agree it makes TDD obsolete. I just do not see how you would have to choose one over the other, to me they are complementary.