Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Looking at Test-Driven Development

DZone's Guide to

Looking at Test-Driven Development

Test-driven development involves lots of coding and refactoring. After some configuring, you can run tests automatically when coding with Visual Studio in C#.

· DevOps Zone ·
Free Resource

The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.

TDD CycleA few weeks back, I attended a talk at Agile Yorkshire about test-driven development (TDD) by Dr. Oliver Shaw. I was impressed at how easy the Oliver made it look, so, as I have never tried it, I thought I should give it a try.

TDD is a way of development that starts with writing a unit test. First, you write a failing test. Then, you write the code to make it pass. Then, you refactor your code. This can be remembered by thinking of "red, green, refactor" — "red" being the failing test, "green" being getting the test to pass, and "refactor" being the refactoring.

During the demonstration, Oliver used a language called Scalar and a system that automatically reran all the tests after every change. I code with Visual Studio in C#... is there a way I can get my tests to run automatically, as well?

After a bit of googling and configuring, I can answer this as "yes."

The Nuget package called Giles is a watcher that will rerun your tests similar to how Oliver did it with his scalar environment. Fans of Buffy the Vampire Slayer will get the joke of why a watcher is called Giles. I couldn’t get this to work with MSTest, but it works fine with NUnit. There is a PowerShell script giles.ps1 that which you need to run and that will update every so often with how many tests have passed or failed. However, you may not see this if you are coding in Visual Studio, but there is a way to get a notification.

If you install the application Growl, you can get notifications from Giles that pop up and then disappear. So, whatever you have on the screen, you can find out almost instantly if you have broken tests.

Another thing that I wanted to configure is a way of viewing code coverage and which methods are tested and which aren’t. If you are familiar with VSTS, after a build, it gives you a percentage score for test coverage. I don’t find this overly useful, as it doesn’t tell you what is covered and what isn’t. Also, what if you want to use GitHub? How do you calculate the code coverage then?

The Nuget packages OpenCover and ReportGenerator allow an HTML report of code coverage to be produced. I created a batch script that can be run whenever you require this information.

[path]\OpenCover.Console.exe -target:”
[path]\nunit3-console.exe” -targetargs:”
[path]\Test.dll” -output:”[path]\coverage.xml” -register:user
[path]\ReportGenerator.exe “-reports:[path]\coverage.xml” “-targetdir:[path]”

The commands are fairly straightforward; the only tricky bit is sorting out all the file paths to the different programs.

Now that I have all this plumbing set up, it's time to give TDD a try and see what I can build!

Interested in Kubernetes but unsure where to start? Check out this whitepaper, A Roundup of Managed Kubernetes Platforms from Codeship by Cloudbees, for an overview and comparison of Kubernetes platforms. 

Topics:
devops ,software testing ,test driven development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}