Blogging Pubbitch

A couple more thoughts about the TestEnvironments that I wrote about previously. Most of my feelings and thoughts about them is derived from Domain Driven Design's ubiquitous language.

When talking to a developer or a QA they tend not to talk about "the acceptance test environment where the web server is bound to port 8080 and the database should be in-memory and contain a certain amount of test data" They tend to talk about the "acceptance test environment" or the "functional test environment", and by using those labels they know that one has an appserver running remotely and a database that's pre-loaded with test data and the other one is just an in-memory database. As such, I like my code to talk about the AcceptanceTestEnvironment and the FunctionalTestEnvironment.

Which leads on to another thing that's been buzzing around my head, and that's the fact that there's normally at least two domain models that are extant within a code-base; one in the application itself, and one in the tests that surround and support this code. The interesting thing is that quite often the same domain concept, such as User or Account, gets referred to in both places. Does this mean that the same classes representing these concepts be used in both places? I'd suggest not. Although they both happen to have the same name, they typically refer to completely different things. One refers to the abstract concept within the application, and this has radically different roles and responsibilities to the other, the on-screen representation that's used within the acceptance test code.

The logical extension of this is that the test code should have its own ubiquitous language that may mirror that of the application but may be very different. This means that testing code, which sometimes doesn't get the TLC that it deserves, needs to be approached with the same sort of rigour that production code should be approached with.

Well, that's what I think anyway. I should really get comments up and running shouldn't I?