Where do the mocks live?

| 0 Comments

During the recent library adjustments the main aim was to add tests. As we write tests we create lots of mock objects. Our libraries are dependant on each other, as libraries tend to be, and this means that often a library uses an interface from another library... When it comes to test the dependant library it's often handy to be able to use the mock object that you created to test the library that you're dependant on... If you see what I mean... The, slightly labored, point being, it's important where you keep your mock objects...

Since we're just making this up as we go along and, in my opinion, any tests were better than no tests, we didn't sit down and plan how we were going to write tests; we just wrote them. This worked for a time. Well, actually, it worked whilst we were writing tests for one library and it started to fall apart as soon as we started testing another library and found that we were beginning to create duplicate test code...

The duplicate test code lasted longer than duplicate production code but eventually the smell was too great and we ripped it out. This involved creating a test library to contain the common test harness code; exceptions, log classes, etc. The test library removed the bulk of the easy duplication but still left us with a problem; the mock objects for testing library A were compiled as part of the test for library A and the test was an exe. When we wanted to use a mock object from library A to test library B we either had to duplicate the mock or jump through hoops to compile the code as part of the test exe for library B. This didn't seem right...

So now we have a slightly more complicated library structure. If library A lives in a directory called ATools then its test harness executable lives in ATools\Test, but that's just code for the actual tests; the mock objects live in a separate library ATools\Mock which the test harness for library A links to. The advantage of this is that if the test for library B needs to use a mock object from library A then all it need do is link to A's mock library...

The project structure is fractionally more complex but at present it seems to be worth it for the flexibility...

Leave a comment