Project Reference Coupling vs Unit Test Value.

June 13, 2008

Today I had a very interesting discussion with my colleagues at work. Before I dive into what the topic was, it is necessary to give some background of the architecture of the code.

We have split up both conceptually and physically our order management system from our online store. From here on the online store (containing 20+ projects) will be called “Online Store Solution” and the order management system(containing 4+ projects) will be called well… the “order management solution”. The way they communicate is through WSE 3.0 Web services. One cannot function without the other as they are dependant but we have decoupled them in a sense that both solutions are buildable without each other. There are no direct project or DLL references between the 2 solutions. Still, they just can’t do much with out each other. Now that I have explained that we can continue on with my story of what happened at work today. The online store solution had some new project that I added and so I also added a new unit test project to go along with it. One of those unit tests was a data driven test. It required that I store something that was generated in the online store solution, in the order management solution. The problem was, that if I used any of the existing methods from the OMS (Order Management System) that they would be filtered through the business logic (all 1000+ lines of code worth) and so it was not feasible to generate some test data to satisfy all these business rules. So the sharp people out there might be saying by now, why not mock the test? Remember, it is a data driven test so mocking it defies the purpose. So what I did was, add a dll reference to the DAL from the test project in the online store to the order management solution and thereby cut out all the business logic. Now essentially what I have done is introduced a coupling between the projects. This is merely a development experience coupling though. The integration coupling already exists and has not changed. Now here’s the interesting bit. We all expressed our opinions and views on this and came to the conclusion that the team would rather comment out the whole unit test and dump it than keep the reference coupling. They stated that in some time in the future we could spend the time in creating some dummy data that satisfies the complex business rules but obviously that time will be… never. I ended up finding a good alternative which I won’t state here because it’s out of scope for this blog post but my interesting point in this story to make is that some developers would prefer a decoupled solution over unit tests. Not a move I personally agree with. What do you think?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: