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

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

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!

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
devops ,software testing ,test driven development

Published at DZone with permission of Simon Foster, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}