Visual Studio Unit Testing – Reducing Redundant Tests

When I first started unit testing, I tested as many methods as I could.  These included public and private ones.  A bit of searching on the web about public versus private method testing will yield mixed results.  I personally test both since I aim for at least 70% code coverage.  Visual Studio creates Accessor classes for private methods and properties for you so testing private methods is easy.

I used to write at least one test per method (some require more than one to test conditional code paths), but this can get redundant.  The steps I take to reduce redundancy today are as follows.  First, I turn on code coverage.  This will give a visual indicator of what has been covered in my classes. 

When I run my tests, code that has been covered is in blue and the code that hasn’t been covered is in red.

I test my constructors first, then public methods, and finally private methods.  Doing it in this order gives me a better idea of what private methods need to be tested.  Most of the time public methods will call private methods so writing a single test will cover those methods as well.  I collapse whatever has been covered each time I create and run a test.  Doing my tests this way has greatly reduced the number of redundant tests written and has kept the same amount of code coverage.

My Thoughts On Scrum (Part 1)

If you’ve been following Greg's Blog, you’d know that our team (and our whole development group for that matter) is now using the Scrum methodology for software development.  I think it’s natural for anyone to get excited or somewhat nervous when a change in day to day operations gets implemented. 

Some people thrive on a dynamic lifestyle while others can’t handle change very well.  For a software developer, the only things that are certain are death, taxes, and change.  Being thrown into something new shouldn’t make your world flip upside-down.

Before Scrum, our team didn’t have a distinctly defined system.  It was definitely iterative and agile, but there were no hard release dates and no administrative tasks associated with our development.  Our team is very customer focused, so transitioning to Scrum didn’t really change our mentality on what we delivered, just how we delivered it.

The hardest part for me when we transitioned to Scrum was the administrative tasks.  Updating statuses, work hours, and general commenting on work items was new to me (and I’m still learning to get used to it).  However, I do understand the importance of these tasks since our sprint burndown chart gives us a great visual representation of our status.

I was assigned to my own project before Scrum and I felt solely responsible for it. Now that we’re Scrumming and there are four of us are working on the same project, I feel a deeper sense of camaraderie.  There’s less sense of I and more of us. 

I think our first sprint is going very well and I’m very happy about what we’re going to give to our customers at the end of this sprint.  As we become more experienced with Scrum, I’ll share some more of my thoughts.