The Problem Domain
>
This is only the HTML version of the original WiKi-based tutorial.
You should download it from here to experience the real thing.
The target audience of this tutorial are developers. Testers and experts interested in FIT are welcome, but these books might be more suitable for you. This tutorial is thought as a quick technical introduction to FIT (and FitNesse of course).
If you feel tired right now, take a nap.
So what's wrong with Unit tests? Well, for functional testing unit tests are quite fine. The problems come with testing the business logic. Business rules are usually defined by domain experts (in small projects there may be no dedicated domain expert, the customer itself is the domain expert). If you are writing unit tests, maybe even doing TestDrivenDesign, you have to understand the business rules to write the right tests. But you are not the domain expert, so every thing specified by the expert is interpreted and translated to a test by you. And here is the pitfall: things can be misinterpreted. And everytime the spec changes there is the chance to misinterprete things or even leave out some aspects.
So perfectly the domain expert would write the tests. But domain experts are not developers, they don't want to write unit tests. To them, unit test code reads like an old Goa'ould dialect. They write specifications. And that's where FIT comes into play: FIT allows writing testable specs. So the developer no longer has to interprete things, but develop code against these specs. This means FIT provides a clear separation of concerns.
Another thing that's great about this approach is that it forces the domain experts to be very precise. What do ya mean by that? We domain experts are as precise as swiss clocks! Calm down. I guess you also have had this experience: You read/write a spec and think it is precise. But when the developers start to write code a bunch of questions come up. This is because specs usually concentrate on the obvious things. The minor details are often handled very fuzzy: Er...we will do it something like that. And often it turns out that we can't do it something like that. If the domain expert writes tests she is forced to even think about these minor details, so problems will show up much earlier and we can avoid playing Spec-Ping-Pong.
You think this sucks? So I failed to convince you in these few words. Shame on me.
You think this might work and you want to read more? Let's start with our problem Domain.
[.FrontPage] [.RecentChanges]
This is only the HTML version of the original WiKi-based tutorial.
You should download it from here to experience the real thing.
The target audience of this tutorial are developers. Testers and experts interested in FIT are welcome, but these books might be more suitable for you. This tutorial is thought as a quick technical introduction to FIT (and FitNesse of course).
Why unit tests are not always appropriate
Once upon a time, there were Unit tests. When they had learned how to write Unit tests and therefore testable software, the developers were happy...QA was happy...management was happy...Since software quality was raising, refactorings no longer seemed harmful, and the end of unmaintainable code was in sight.If you feel tired right now, take a nap.
So what's wrong with Unit tests? Well, for functional testing unit tests are quite fine. The problems come with testing the business logic. Business rules are usually defined by domain experts (in small projects there may be no dedicated domain expert, the customer itself is the domain expert). If you are writing unit tests, maybe even doing TestDrivenDesign, you have to understand the business rules to write the right tests. But you are not the domain expert, so every thing specified by the expert is interpreted and translated to a test by you. And here is the pitfall: things can be misinterpreted. And everytime the spec changes there is the chance to misinterprete things or even leave out some aspects.
So perfectly the domain expert would write the tests. But domain experts are not developers, they don't want to write unit tests. To them, unit test code reads like an old Goa'ould dialect. They write specifications. And that's where FIT comes into play: FIT allows writing testable specs. So the developer no longer has to interprete things, but develop code against these specs. This means FIT provides a clear separation of concerns.
Another thing that's great about this approach is that it forces the domain experts to be very precise. What do ya mean by that? We domain experts are as precise as swiss clocks! Calm down. I guess you also have had this experience: You read/write a spec and think it is precise. But when the developers start to write code a bunch of questions come up. This is because specs usually concentrate on the obvious things. The minor details are often handled very fuzzy: Er...we will do it something like that. And often it turns out that we can't do it something like that. If the domain expert writes tests she is forced to even think about these minor details, so problems will show up much earlier and we can avoid playing Spec-Ping-Pong.
You think this sucks? So I failed to convince you in these few words. Shame on me.
You think this might work and you want to read more? Let's start with our problem Domain.
[.FrontPage] [.RecentChanges]