Category Archives: TDD

ASP.NET MVC Test Template Project for NUnit and Moq

If you have been following along with ASP.NET MVC, you know testability is a big part of the story. This fact is really driven home when the option to create a test project immediately follows that of a ASP.NET MVC Web Application. This is all really cool – especially the flexible test project templates.

Out of the box, you get the “Visual Studio Unit Test” set which features 25 opinionated Home and Account Controller tests. However, you are not limited to just this template. Nope. You can build your own test project templates (New Project –> Add References, etc –> File –> Export Template), jump through a few hoops (update the vstemplate file settings, copy the exported files to %Program Files%\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\Csharp\Test\1033, execute devenv /setup, wait a while and then update the registry) and have your own test frameworks appear in the “Test Framework” selectable list. It’s just that easy. 😉

My team is currently using NUnit and Moq so this afternoon I exported a custom template project and put together an install script which I based somewhat on the NUnit MVC Preview 3 Templates.  After a few attempts, it all came together.

imageAfter running the .bat installer (Install NUnitWithMoq.bat), you will find the “NUnit with Moq” template listed in the “Test Framework” dropdown (see above screenshot .) The new template will also appear under the Test project type templates.

image

The template includes references to the moq.dll and nunit.framework.dll.  Since there’s no way of knowing where each of these files will sit on your machine, the templates make the assumption that they will be inside an “External Dependencies” folder which lives side-by-side with the test project.  I suggest putting your “External Dependencies” folder/files in place before you create your MVC and Test project.  You shouldn’t have any troubles if you follow this pattern.  If not, you’ll merely need to reset the Moq and NUnit references once your test project is created. No big deal.

image

I’ve provided a screenshot of a sample solution after a new ASP.NET MVC Web Application (MvcApplication1) and NUnit with Moq Test Project (MvcApplication1.Test) are created.  As you see, the web project, Moq, NUnit and a handful of other references are included in the test project by default.  image

The provided tests are basically a ported from the “Visual Studio Unit Test” template.  There should be no surprises here as all tests should pass from the get go. Please note that I have only included the C# template for the full version of Visual Studio 2008.  I have also included an uninstaller script (Uninstall NUnitWithMoq.bat) so you may install with little worry.

Download NUnit and Moq ASP.NET MVC Test Template: NUnitWithMoq.zip

Update 04/03/2009: If you are running VS 2008 Standard Edition, refer to Nicolai Stoy’s comment which calls out how to update the install .bat file.

VS2008 Test Project Tips

As I mentioned last week, I am new to TDD.  For better or worse, all of my tests (and spikes) have been generated via Visual Studio Test Projects.  Working with VS Test Projects hasn’t been all that bad although I noticed a couple of annoyances right away. 

Is anyone else bothered by the fact that, by default, an unlimited number of test results and binaries are “deployed?”  If you are testing first, this arguably makes for a lot of useless activity and waste disk space.  Since the default TestResults folder location is set to be side-by-side with your solution files, the extra folders, trx files and binaries can also really interfere with your otherwise easy source control check-ins. 

Fortunately, there are ways to work around the excessive TestResults problem if you are running VS2008.  Some options are available through the IDE and other require an update to the .testrunconfig file directly:

Limit the number of deployed tests:

Tools > Options > Test Tools > Test Execution > Test Results Management > Limit number of old Test Results to the value of your choosing. 

The screen shot below sets the number of tests to one.  Therefore all previous tests are purged and only the latest test is maintained.

image

Disable Test Result deployment:

If you wish to disable the Test Result generation completely, double-click on your solution’s .testrunconfig file and uncheck the “Enable deployment” option.  No results will be generated thereafter.

image 

Change the Test Result folder location:

This option is hidden.  I don’t believe it is exposed in any of the VS 2008 dialogues and you have to edit the .testrunconfig file directly. 

Right-click on the .testrunconfig file > Open With… > XML Editor > Include the following within the TestRunConfiguration node:

<Deployment useDefaultDeploymentRoot="false" userDeploymentRoot="C:\TestResults" />

I hope it helps.

References:

Learning Test Driven Development

I am relatively new to the Test Driven Development (TDD) scene.  Though I have read up on the subject (specifically Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela), my only hands-on experience is limited to a single, 3-month project where I was the lone developer.  All other information gathered on the subject has been through blog entries, podcasts, ramblings and the occasional deCover Imagemo in the office.  Though I believe I have a good understanding of TDD methodologies, I am far from putting this, dare I say, knowledge to practice.  Good practice, that is…

A spike is a term associated with TDD.  A spike is nothing more than quick coding exercise which validates or invalidates an assumption.  Lasse Koskela says it more eloquently:

A spike is a short experiment with the purpose of familiarizing ourselves with the technology, tools, algorithms, and so forth, that we need for solving the problem at hand.  A spike is  a way to make an unknown known — at least to a point where we know whether it’s worth continuing to dig that way or whether we should start looking for another way.

If you are familiar with TDD concepts, you know that spikes offer no value with it comes to testability, maintainability, etc.  They are merely quick prototypes which I find immensely helpful but should not be considered the focal point of TDD.  Well, my first crack at TDD resulted in roughly 70% spikes and 30% actual tests.  Not too good.

There is no doubt in my mind that I always had the best intension to test-code-refactor, but I wasn’t yet familiar enough with TDD to know I was way off course. There was also no one around to put me on the right track (or keep me honest.) Putting my ego aside, I know I could have used some hand-holding when I was starting off with TDD.

Test Driven Development is a discipline.  Like many other disciplines, TDD requires a teacher, student and practice.  The teacher offers instruction and ensures the discipline is practiced correctly.  The good student gathers knowledge and implements under watchful guidance.  In my opinion, TDD is therefore a seemingly good fit for a team which embraces an Agile approach, collaboration, rapid development and testability.   I’m not saying the lone developer with no prior experience with TDD is not capable of learning TDD on their own. I know some are.  I know guys who have done it.  Simply, I am stating that TDD seems most accessible to the mentored developer working with team members who previously adopted the methodology.  To put it another way, I bet Test Driven Development concepts are best learned through practical, hands-on example.

I haven’t given up on TDD yet.  Who wants to hold my hand?

Question Everything

You may have noticed the recent attention given to TDD and whether it has been proven effective or not.  I think the entire “conversation” is great.  I appreciate everyone’s position primarily because the parties appear to be presenting their opinions and the interpreted facts with open minds.  If I were to take sides, though, I think I would be in favor of the “Not” argument mostly for the reasons I commented about on a recent post by Jon Galloway:

You know, it is pretty easy to read the popular blogs (especially the ones which make references to “alpha” programmers) and think their way is the right way.  I take a lot of pride in [dev stuff], but if I hadn’t been in this business for a while, what-every-developer-must-know type posts could really get me off track.

Please do not interpret this as a knock on the “popular blogs.” I like them a lot, but what I love is the fact that Jacob Proffitt took the time to challenge the TDD effectiveness evidence.  It isn’t for a lack of trust, it’s just that as developers it is our job to question everything.  Equally, it is our job to validate everything. 

I literally just wrapped up a meeting with one of my lead developers.  We are just over a week away from rolling Version 2 of an application to our Production environment and today — one day after our final QA release — he discovers where Version 1 of the product lives and what it is *really* doing.  Why did it take so long to find out the real story?  Well, he (really we, I am equally responsible) trusted documentation and what past developers shared with him…and now we are in a bit of a pickle. If only we verified earlier. Fortunately, this kind of thing doesn’t happen often, but I’d be willing to bet that something questionable crosses each of our paths every single day. 

Back to the TDD effectiveness conversation. Here’s my semi-confirmation bias story as it relates to TDD… 

I worked at a shop where fingers were pointed towards Development no matter what the technical issue.  The web server lost connectivity to the app server.  Database XYZ hasn’t been backed up for 8 weeks. The L Drive has only 97KB available.  Two new defects were just introduced into the Production Environment after four months of testing.  A third party web site is down.  Quick, call the Developers.  Don’t call Networking.  Don’t call the DBAs.  Don’t call the NT Admins, the QA group or the third party site owners.  Call the Developers.  Maybe you are familiar with such a place?  Anyhow, since Development clearly had to straighten up its act, we needed to provide evidence (there’s that word again) that we were putting more care into our code and validating our applications prior to release.  Thus, TDD was introduced to my shop.  We found the perfect guinea pig project — an Enterprise Messaging System (read: glorified email engine.)  It was simply a service which sat around waiting to complete requests issued by a handful of web applications.  For this app, we did true TDD as we actually wrote the tests before the code.  All the tests passed and we rolled the service to QA and, lo and behold, not a single defect was logged against the Enterprise Messaging System.  It was deemed perfect. The greatness of TDD was soon shared at the quarterly IS meeting using the first-ever defect free application as evidence of its brilliance.  I think those who pushed for TDD were hoisted on shoulders and paraded around the conference room as Development had finally had gotten their sh*t together. 

If truth be told, instead of praise and congratulations, everyone should have been asking a whole bunch of questions.  Was TDD really the reason for the bug free code — directly or even indirectly?  Was a superior product released because time was taken to validate all of the tests?  Perhaps merely taking the time to write the tests before coding gave Development a needed boost?  Well, these questions certainly couldn’t be proven either way.  What about the zero defect count providing evidence that TDD was our saving grace?  Very simply, there was no relationship between TDD and bug free software at all.  In fact, the service had bugs, but no one other than the developers knew it.  All bugs were logged against the calling web apps (as testers couldn’t interpret the difference between a web app failure and a service failure) and fixes were applied to the service unbeknownst to the folks looking for the last great Development hope.  It was all a matter of sharing only the information which supported Development’s case as well as stretching the truth a bit. 

If you look hard enough this stuff happens every day whether it be accidental or intentional.  Though it is exhausting, it isn’t a bad idea to question everything — or not.  The choice is yours.