Test Driven Development vs working at the right level of abstraction
I like the idea of TDD. I think it could be a good fit for a part of the kind of development I do, but I still don't have the discipline it takes to start doing it.
On the other hand, suppose we could write something like:
throw NotEnoughInventoryException if Product.Inventory < 0;
and we had a framework that ensured that the constraint will be checked in the right places (the UI, the business logic layer, the database, whatever). Let's suppose that framework is already built and tested by whoever built it.
Now suppose I want to write this code in a TDD way. I will start writing a test that will set the product Inventory in -1 and try to save it. The test will first fail, then I'll write my implementation code, and then it will succeed.
But I'm actually a little (OK, more than a little) lazy, and I want the same test to work for the Win UI, the Web UI, the Business Logic Layer, the database, whatever, so I write a framework that let's me write something like:
throw NotEnoughInventoryException if Product.Inventory < 0;
and generates the code for the tests.
Now I start feeling a little stupid, as I'm writing the same code twice, one for the test and another for the implementation.
I can't help thinking that if we could write code at the right level of abstraction, then we won't need TDD or even Unit Testing. No one (I hope) writes a test to check if a statement like 'a = 1' works OK.
That's probably why I feel DSLs are much more interesting than TDD.
If we had a language that lets us express ourselves in the right level of abstraction, would we need TDD or Unit Testing?
Any TDD converted can help me here?