Igor's Blog

public void testShouldRecordSystemException(){
     exceptionMonitor.recordSystemException();
     assertTrue(exceptionMonitor.getCurrentCount());
}

public void recordSystemException() {
storeNewTotal(++currentCount);
}

public void testShouldRecordSystemException(){
         assertEqual(1, exceptionMonitor.recordSystemException());
}

public int recordSystemException() {
   storeNewTotal(++currentCount);
   return currentCount;
}

public int recordSystemException() {
    return 1;
}

public void testShouldRecordSystemException(){
     for(int n = 1; n< 5; n++){

       assertEquals(n, exceptionMonitor.recordSystemException());

     }
}

I would argue that, by changing the return type of recordSystemException(), you've exposed the state of your exceptionMonitor in the same way that a getCurrentCount() method would. How is that better than changing a method from private to protected? Would code that uses the exceptionMonitor object actually care about the return value? Is that the way in which the exceptionMonitor is useful? Maybe all you want is a count of the number of exceptions recorded, but in that case an accessor is exactly what you want to test.

I'm guessing that's not the case, though. Does the exceptionMonitor write an exception to a file? Mock the file object and make sure something relevant gets written to it. Does it use a Log object? Mock the log. Does it write to a database? Mock the database. Does it record to something, but you don't know exactly what? Then you should have an interface on top of the various implementations (file, log, db, etc.) which you can then mock.

I like "verifying observable behavior" as a phrase, but I think that the behavior observed should be natural to how the code is actually used, not an artificial observation that is provided only for testing purposes.

Brian, thanks for the good comments you provided to my post.

You raised all valid questions and concerns and I agree with most of them, but the point I was trying to make is that all of them have pros and cons and I am looking for some kind of middle ground. I would try to clarify my point a little bit more here, but I am very happy with your questions, because I have asked them myself many times and still looking for optimal answers.


>>>>

I like "verifying observable behavior" as a phrase, but I think that the behavior observed should be natural to how the code is actually used, not an artificial observation that is provided only for testing purposes.

<<<<


Completely agree with the notion that we should not create additional stuff just for testing. However, when you create your object (domain object for example) you have some idea how it would be used (for example, you know that your object should expose “recordSystemException”) but you don’t know all the details, especially if you start from your domain objects first (bottom to top approach). Almost all the time, I had to go back and redesign or add additional methods to my domain objects based on things that I discovered later (like we need a getter method for the UI that wasn’t specified and so on…). So, I look at testing, not only as a verification whether the code is working or not, but also as a very substantial for the design of my objects. In this particular case, I needed the current count after recording to check whether a service should be blocked or not but this is out of context.

I believe that by having such methods not returning anything, you don’t specify behavior and you leave the caller to figure out the result of calling such a method. To give some analogy - this is similar to a situation when you want to ring a bell in a big building. You get in front of the building and ring the bell. (Basically, you call method ringBell()). Now, there are places that you hear some sound when you ring the bell, but in other places you don’t hear anything and you wonder whether the system is working at all or not. I agree that the fact that you hear(or don’t) a sound doesn’t mean that the people that you are trying to reach hear the bell too, but at least the system is giving you some indication that is working. Obviously, this translate to a method ringBell() with return type of either void or boolean (or some kind of “Sound” type if you want to be fancy).

In both cases (with return value or not), the caller will (or not) achieve the desired result, but I argue strongly that home systems that are design to indicate in some way that the bell is ringing are better designed system than the ones that don’t indicate. (I know that now we use cell phones for that purpose, but the UPS guy is still using the bell :-))

To finish with this point, this topic is very similar to the debate about human interfaces vs minimal interfaces (http://martinfowler.com/bliki/HumaneInterface.html ) or to
fluent interfaces (http://martinfowler.com/bliki/FluentInterface.html).

>>>>>>>>>>>>>>>>>>>>

Does the exceptionMonitor write an exception to a file? Mock the file object and make sure something relevant gets written to it. Does it use a Log object? Mock the log. Does it write to a database? Mock the database. Does it record to something, but you don't know exactly what? Then you should have an interface on top of the various implementations (file, log, db, etc.) which you can then mock.

<<<<<<<<<<<<<<<<<<

Yes, I am not sure to what recordSystemException() is supposed to write (database in my case, but this is out of context again). That’s why I designed the MonitorException object to delegate the storage responsibility to Repository object, which hided all of details about storage. ….and yes, Repository have an interface, …and yes, it is very easy to create a Repository mock and test it with mocks, …and yes, you will test the right behavior without breaking the encapsulation, … and yes, it would be a very good solution.

However, this was the point of the presentation. I would not repeat everything again, but very briefly – there are some negatives together with the positives when using mocks and the biggest negatives are exposing implementation details (which in my opinion is worse than exposing state) and difficulties with refactoring and maintaining tests. I agree, however, that using mocks sometimes is the better solution and this could be just preference, but in that particular case, if I use mock for Repostiory (which is interactive testing), I would expose unnecessary implementation details, because I have to interact with Repository…. and yes, Repository is an interface, but you don’t need to know about it when you test “recordSystemException”. Again, this could be preference based, but I believe that there are consequences of using mocks in this case that I tried to indicate in my presentation.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I would argue that, by changing the return type of recordSystemException(), you've exposed the state of your exceptionMonitor in the same way that a getCurrentCount() method would.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Well, here I respectfully disagree. Probably, I should’ve change the return type to “boolean”, or return a “success” in form of “string” instead of “int” in order to demonstrate the idea better, but this is totally not exposing the internal state. I already gave the example with the door bell above that this is not exposing state, just “exposing observable behavior" and the definition for that is that I can change the return type at any point without changing any state on the object.

Again, most of those debates are coming to personal preference and prior experience with design and testing but definitely these comments raise very good points.

Thanks again, Brian.