3

How do you test, or do you test at all, classes that convert some other data model/structure into your data model? 

interface ToTradeObjectConverter<T> {
    public Trade convertToTrade (T source);
}

public class Trade {
    // here we have ~ 100 fields, like dates, account, currencies, etc.
}

The converter just populates Trade through setters, getting data from another object or parsing a text or XML or whatever.

Would you test such a class? If so, what is a good approach? I don't want to mock (EasyMock) arguments and add 100 lines of "easy mock expect proper getter and setter invoked".

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
magulla
  • 499
  • 1
  • 9
  • 22

1 Answers1

3

If these classes are automatically generated, or if they are hand-written but never do anything interesting to the input (they just copy it), AND if you have integration coverage, I wouldn't test them. (I'm coming from a BDD perspective here: make the acceptance/integration test(s) pass first, and then unit-test-drive the rest as necessary.)

If these classes do something interesting, and/or if they don't have integration coverage, test them.

I would definitely not use mocking. These appear to be simple classes which do all their work in memory. I think the secret to testing these classes without too much pain would be to give them all robust .equals methods (if they don't have them already). You can probably generate them. Then your unit tests will be something like

public class ToTradeObjectConverterTest {
  @Test
  public void convertToTradeReturnsTheExpectedObject() {
    TradeSource source = new TradeSource(/* whatever goes here */);
    Trade trade = new ToTradeObjectConverter<TradeSource>().convertToTrade(source);
    Trade expectedTrade = new Trade(/* whatever goes here */);
    assertThat(expectedTrade, equalTo(trade));
  }
}
Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
  • agree with you code. Just was wondering maybe someone came up with soultion to avoid creating real objects with hundreds of fields. – magulla May 02 '14 at 18:11
  • I was just answering the question you asked, but I agree -- if your system has a lot of classes like this you should reconsider your architecture. Do both the source classes and converted classes do interesting work? If not, maybe you can replace them with a single source class and/or a single converted class that holds the data in a generic way. Or maybe you could just replace them with JSON documents or some such. – Dave Schweisguth May 02 '14 at 18:45
  • Classes have no logic, just carrying data. But I insisist on having domain models as wrappers for most of data. So let's say instead of having proeprty "price" as BigDecimal we have Price class. Using one class or use data holder like map or json document are not proper OOP approach. However you gave me idea: what would I introduce back all my data type with let's say map. – magulla May 05 '14 at 21:51
  • good argument here: http://yojava.wordpress.com/2011/06/17/why-i-prefer-pojos-to-maps-for-domain-objects/ – magulla May 05 '14 at 22:08
  • I like real domain objects too. You just need to decide whether they provide enough value in your architecture to justify the effort of creating and testing them. I'd say that if you have an anemic domain model (http://stackoverflow.com/questions/258534/anemic-domain-model-pros-cons) it doesn't matter whether that model is hand-written, code-generated or stored in (type-checked) documents. – Dave Schweisguth May 06 '14 at 11:42