XpdWiki
Set your name in
UserPreferences Edit this page Referenced by
JSPWiki v2.0.52
![]() ![]() |
I (MarcuS) have taken to grouping our (Wordtracker, Roach) tests into the following... Unit tests: These are tests of single classes that interact only with other classes in the system or with libraries that involve no I/O. This means that any contact they have with the outside world can be mocked (MockObjects) or otherwise completely controlled. Complete padded cells that can be completed as fast as the processor will allow. This is very handy once you are in the habit of clicking test after just about every edit. Boundary tests: Of course an application that has no contact with the outside world is pretty useless. Real applications use interfaces that do things. Let us assume that we have had the good sense to wrap these interactions for mocking in other tests. We will also want to keep these objects as simple as possible as any extra behaviour can then be transferred to the unit tests. Testing is quicker that way. Now, the classes that are left form the boundary of the application and to test these we need something real to happen. These tests are slower and need to run less often than unit tests. That makes them different to me. Besides...they are also useful during deployment as a check that required components are installed. Acceptance tests: Actually we call these system tests. They aren't actually required to pass at all times, only as part of the roll out script (to a live server). An acceptance test will often be added at the start of an iteration. If we don't get it working then it will just be commented out during deployment. The test group forms a use case like specification plus various sundries like performance criteria. Integration tests: This can end up as a catch all and this is what worries me. A simple definition is a test that involves more than one class in the application. If there are no boundary classes then this type of test can be placed straight into the unit tests without trouble. Normally we are not so lucky. If a small number of classes and a very small number of boundary classes is involved then the boundary classes can be mocked. As things get more complicated we need a kind of scripted mock, usually created especially. Pretty soon even that breaks down and we need a test environment.
|