Skip to main content

MSTEST unit tests & deployment problems

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.








Then make sure these test settings are the active ones, i.e, currently being used by your solution's unit tests:



In an ideal world this is where this post would be ending, but ... it is far too often the case that you add a deployment item, be it a folder or a file, hit apply and run your unit test only to find out the items you've specified ARE NOT COPIED alongside your unit test (commonly referenced as "Deployment items not working").

Now, unless carefully handled, this may lead to a considerable amount of frustration building up inside of you, threatening your metal well being. Rather than turning to Prozac, you should instead restart your solution (As in close, then open. No need to restart the VS). Once the solution restarts, the deployment items should be in effect and the specified items should be copied, at last.

Hooah!

Comments

Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

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.