I came, I coded, I debugged.

The Good Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI , numerous DI frameworks have arisen ( Spring , Guice , Castle Windsor , etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application. I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same. 

When asked about what's a module, no two people give the same answer. The interesting thing is, it doesn't keep modularity from being one of most pronounced words when it comes to the desirable set of attributes a software system should ideally have. It's somewhere just next to scalable and robust, in no particular order.

There is no easy way to say it, the default Jenkins plugin for publishing MSTEST results does not show a unit test's standard output when it fails .

Unit tests are sometimes thought of that cousin nobody likes and everybody can't wait for him to leave, although he gets invited regularly because, well, what are you going to do? - He's family. Whether we write unit tests because we believe in them, or because somebody insists that we do (be it your team leader, some agile guideline, the Pope, etc.), there are ways to make the end result more effective, and dare I say - fun.

Every now and again you might require for some additional resources to be present in order for your unit test to properly execute. This seems as a reasonable requirement, and MSTEST has indeed addressed it with what goes by the name "Deployment". To configure deployment for your unit tests double click the "Local.testsettings" in your "Solution Items" folder, you should be able to see a "Deployment" option on the left side, allowing you to add files and folders to be copied alongside your unit tests. So far so good.