We have such a DSL for testing language implementation (it will probably be available in the next MPS build). For example in it, you can annotate you program with special notation which requires that a particular expression has a type you set. Another use case is testing of refactorings (like extract/inline method). They have a lot of special cases to make them look intelligent which makes them very error prone. In these tests you specify how code looks before and after refactoring and test checks this with respect to refactoring implementation.

On the other hand, not all projects require unit tests. If you are creating prototype or a proof of concept application, it’s almost always a bad idea to write unit tests since they slow down experimentation. Why writing unit tests for code if you are 90% sure that you will throw it away. As project and its architecture mature it test stop slowing it down and improve its quality.

1- Unit tests are code, and if you write unit tests because there might be some mistakes in your code, then what prevents you from having mistakes in your unit tests as well? My point is: unit tests are by no way a proof of anything. If you want to prove that your code is doing what you expect it to, then you’re stuck with formal programming, something like B for example.

2- Unit tests do NOT test that your code does what the client expects of it, they test that your code does what YOU expect of it, and in my experience, most of the time, developers are the ones who misinterpret what the client wants, so you end up testing correctly something that does not correspond to what the customer needs. And if THAT’s really your objective, then “my” fancy graphical and high-level representation seems more suitable to spot misinterpretation mistakes than a very local and low-level unit test.

My ultimate goal as a software developer is dual:
- the application should do what the customer expects it to do
- the application should NOT do what the customer does not want it to do

Now those are goals, something I tend do, but I also keep in mind that the closer I want to be to these, the more difficult it is to focus on both goals at the same time. IMHO, unit tests can be useful for the second goal, but not very much for the first one. MDA does not pretend to remove all bugs, but at least it reduces the probability of bugs, while allowing you to work with a much higher-level view of your application, which is great for the first goal. Of course, I could combine MDA and Unit tests, and I have seen it done on a few MDA projects. But then the question is, is it worth the time and effort… and pain? For me, the jury is still out.

My only point was to open up the debate, because I’m kind of fed up with hearing that unit tests are the only way to salvation, that if you’re doing unit tests, you’re the good guy, if not you’re bad. That’s dangerous, because software quality is not only about bugs, it’s about business value and usability too. And there are various techniques that you can use to improve the quality of your software. And because all those techniques have costs, your software will never be perfect. And all I’m saying is that the cost of unit tests is sometimes too big, big enough for me to look for other techniques to reach similar goals.

So you don’t write a test for every method. Fine. If you drag an arrow to the wrong place in your fancy tool and screw up the system not test will show that mistake. Wrong!

I don’t have a problem so much with the fact that you use fancy tools to generate your software, I have a problem with the fact that you don’t provide proof that it works alongside it.

Especially in an environment where some people are working on the code directly your approach is completely naive. Even if you have generated the perfect code, somebody will come along during refactoring and get no warning whatsoever if he breaks it.

The ultimate goal is working software, which is not the same as correct software. Your tools might generate code without bugs, but they might also generate code that doesn’t do what the client expects of it.

In a way similar to what code coverage junkies do, you value the process over the result in your post. That is the kind of behavior that gives software developers a bad name.