I am trying to test-drive (or at least write unit tests) my Model classes but I noticed that my classes end up being too coupled. Since I can't break this coupling, writing unit tests is becoming harder and harder.

To be more specific:

Model Classes: These are the classes that hold the data in my application. They resemble pretty much the POJO (plain old Java objects), but they also have some methods. The application is not too big so I have around 15 model classes.

Coupling: Just to give an example, think of a simple case of Order Header -> Order Item. The header knows the item and the item knows the header (needs some information from the header for performing certain operations). Then, let's say there is the relationship between Order Item -> Item Report. The item report needs the item as well. At this point, imagine writing tests for Item Report; you need have a Order Header to carry out the tests. This is a simple case with 3 classes; things get more complicated with more classes.

I can come up with decoupled classes when I design algorithms, persistence layers, UI interactions, etc... but with model classes, I can't think of a way to separate them. They currently sit as one big chunk of classes that depend on each other.

Here are some workarounds that I can think of:

  1. Data Generators: I have a package that generates sample data for my model classes. For example, the OrderHeaderGenerator class creates OrderHeaders with some basic data in it. I use the OrderHeaderGenerator from my ItemReport unit-tests so that I get an instance to OrderHeader class. The problem is these generators get complicated pretty fast and then I also need to test these generators; defeating the purpose a little bit.
  2. Interfaces instead of dependencies: I can come up with interfaces to get rid of the hard dependencies. For example, the OrderItem class would depend on the IOrderHeader interface. So, in my unit tests, I can easily mock the behaviour of an OrderHeader with a FakeOrderHeader class that implements the IOrderHeader interface. The problem with this approach is the complexity that the Model classes would end up having.

Would you have other ideas on how to break this coupling in the model classes? Or, how to make it easier to unit-test the model classes?

Update after going through the answers:

  • I have done a little more thinking on this problem and noticed that some of these dependencies were not really necessary (as most answers pointed out). The reason why they existed is because my UI layer needed it. Basically, I have inserted these dependencies so that UI layer can easily navigate from child to the header and display some header fields at the child level views. Looking at it now, it looks so simple; however it took some time for me to figure out why these dependencies existed in the first place. Now, the UI will basically keep the header in its context when navigating to the child level views.
  • On the other hand, I have removed some of the dependencies via interfaces. These dependencies were mostly one-to-one; for example between Header and HeaderReport. Previously, HeaderReport depended on Header for retrieving information (items, date, etc...) and this made HeaderReport very hard to test. Now, the HeaderReport depends on the HeaderDataProvider interface and I am able to achieve complete isolation. HeaderReport is very easy to test with stub classes for the HeaderDataProvider interface.
  • It looks easy to create these abstractions (UI Layer - Model Layer - Backend Layer), however in reality, it really takes a lot of practice!
  • What is the value of breaking the coupling of model classes? Since you are not using an OO database, they are coupled for a good reason. In other words if the dependency exists in the domain, why should your class design hide it? – NoChance Oct 9 '12 at 2:28
  • The value is test in isolation. I wasn't aiming for complete decoupling but as it turns out; there were some unnecessary couplings in my design. – Guven Nov 3 '12 at 17:49

Do the classes really need to be decoupled? In your example, from business point of view, the order header and order item are entities, that are really close. They probably form an aggregate. So trying to decouple those will create unnecessary complexity and will make reading the model confusing.

To solve this, I would try to locate aggregates in your code and then unit test whole aggregates.

| improve this answer | |
  • Correct! The aggregates ended up staying in the design (see my update). – Guven Nov 3 '12 at 17:54

I know you're trying to simplify your scenario to make it easier to discuss, but why does the OrderItem care about the Header? The Header is Aggregator (called the "Root" in DDD) and it is responsible for knowing about its components (OrderItem being one of them).

If you're discussing special cases like Discounts being applied to Orders containing for example 10 or more of a certain Item that would be a job of say a discount service to find which discounts apply as the order is being processed.

The same thing would apply to ItemReport...it is responsible for knowing the rules for how the items are selected, filtered, ordered, etc. The Item shouldn't be concerned with reporting, that's not its job.

| improve this answer | |
  • Yes, in the aggregator case, the dependencies turned out to be unnecessary (see my update). For the reports, the Item has a reference to the ItemReport class but the ItemReport depends on ItemDataProvider interface. As a result, ItemReport can easily be tested. – Guven Nov 3 '12 at 17:54

Would you have other ideas on how to break this coupling in the model classes? Or, how to make it easier to unit-test the model classes?

In my opinion, coding against the interfaces is the way to go. In another words, de-coupling your code by design is the approach that modern projects do follow. That greatly helps with the needs of unit-testing.

In another words, it is recommended to define your formal, precise and verifiable interface specifications for software components that you are planning to develop or trying to de-couple to remove dependencies.

| improve this answer | |
  • Can you explain how any of these concepts relate to coupling? – Aaronaught Oct 8 '12 at 20:54
  • 1
    Simply asserting that this phrase has anything to do with decoupling does not make it so. Design by contract specifically refers to preconditions, postconditions, and invariants, which is also what Microsoft's code contracts support. If you're simply advocating abstract data types, then (a) the author already mentioned that and (b) the "design by contract" stuff is irrelevant. – Aaronaught Oct 8 '12 at 21:05
  • @Aaronaught, as author says "I am trying to test-drive (or at least write unit tests) my Model classes" - means that my first paragraph answers that concern. Secondly, author wants break coupling, which is done through interface coding. – Yusubov Oct 8 '12 at 21:09
  • @ElYusubov the notion of breaking coupling through the use of interfaces is correct (although not appropriate in this case). However this is not the same as 'design by contract' which means something quite unrelated. – MattDavey Oct 8 '12 at 21:11
  • @MattDavey, although it implies that in context, i have removed the confusing reference. you may look at that re-phrased statement. – Yusubov Oct 8 '12 at 21:13

One way to do it is, as you said, to create interfaces between the classes. Each class would take its dependencies as interface references that can be mocked or stubbed in a unit test context. This might make you think a bit more about the essential parts of the design that are needed by each class. For example, you might find that the order item does not need the full order header. This process might lead you to discover latent concepts in the design, which will increase the chances of reuse and create elements more inline with their intent, or raison d'être.

On the other hand, maybe creating interfaces does seem odd for such synergistic and coupled concepts. If that's the case, you can use fluent test data builders to create a domain specific and direct way to easily create dependent objects. You don't need to test these builders directly, as they'll be used by test code to create the dependent objects.

| improve this answer | |
  • Yes, creating interfaces really showed me actual dependencies between the classes. It also made the design a lot easier to test. For the rest, fluent interfaces do help. I remember using it in a previous project :) On the other hand, some of my dependencies turned out to be completely unnecessary; due to my misjudgement in the layers (see my update). – Guven Nov 3 '12 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.