Deborah's Developer MindScape






         Tips and Techniques for Web and .NET developers.

June 4, 2014

"I Don’t Have Time for Unit Testing!"

Filed under: C#,Testing,VB.NET @ 12:50 pm

So, be honest, when you hear someone talk about unit testing … what is your first thought?

  • Is it: “I just don’t have the time to do unit testing”!
  • Or “Our management will never approve the time for unit testing”?
  • Or something similar?

Let’s look at what unit testing can do for you:

Save you Time

Yes, that’s right!

Throughout my career as a software developer, I have seen how much time unit tests can save.

Let’s think about this …

  • Any developer that has written more than a few lines of code knows that it needs to be run to verify that it operates as expected. Right?
  • You need to execute the feature to confirm that it takes appropriate inputs and produces appropriate outputs. You may need to go through this process several times.
  • And as you build more features, it requires more effort to manually test it.
  • For example, say you write a pedometer application that takes in a step count goal and an actual step count and then calculates the percent of goal you have reached.
    • To test the pedometer feature you need to execute the application, navigate to the appropriate feature, enter all of the required data, and then validate the results.
    • And if you find a bug you may have to repeat this process again, and again, and again.
    • For the feature you are working on now, how many times have you run the application to try it out? 10? 20? more?
  • The idea of an automated code test is that you can write code to perform that testing.
  • So if you want to test that the pedometer calculation is correct, you write an automated code test that defines appropriate inputs, calls the function under test, and verifies the results.
  • Then when the users want a change to that code (and you know that they will), you can make the change and just re-run the tests.
  • No need to slog through the UI again for each possible set of inputs.

This can save you LOTS of time.

Help you Find Bugs Faster

You just received a bug report. Something in the code does not work.

Instead of trying to reproduce the problem by wading through a bunch of UI, you can instead use your unit tests to quickly reproduce, find, and fix the error.

Allow you to Refactor Safely

So you are working on some code that is just too painful to deal with.

You’d like to apply some refactoring techniques to make the code cleaner and easier to use.

With no tests, you are running a risk of introducing bugs if you rework the code.

If you have unit tests in place, you can safely perform a refactoring because when you are done with the refactoring, you can rerun the tests to confirm that all is well.

Readily Add Features

You can add new features and rerun all of the existing tests to ensure that the new feature does not adversely impact any existing features.

No more worry that adding feature b will adversely affect feature a.

Minimize Those Annoying Interruptions

So you are in the middle of coding the next feature and you have to drop everything because someone entered something bad somewhere in your application and now it is crashing.

Bummer!

Having a good set of unit tests can minimize those annoying interruptions.

Enhance your Value

Don’t you just hate it when the “QA” person emails you to let you know your code doesn’t work?

This is especially difficult if that “QA” person if your boss or your client.

Having a good set of unit tests can make you look like a coding master!

Or what if the person after you changes something and now it looks like your code doesn’t work.

Unit tests help the developers that come after you to better understand and modify your code. They can re-run the tests to ensure the code still works after their changes.

Having a good set of unit tests verifies that your code works over the lifetime of the application.

Conclusion

Writing unit tests isn’t hard or time consuming once you get into the habit. And these benefits look pretty good!

For a gentle introduction to automated code testing, see my Pluralsight course: “Defensive Coding in C#”.

Enjoy!

PS circleCheck out my Pluralsight courses!

3 Comments

  1.   Alan White — June 30, 2014 @ 4:11 am    Reply

    Though I agree with the benefits over a longer time frame, where changes to code that negatively impact the product will be found with automated testing, I can honestly say that (IMO) it does simply take far too long.
    Once the mocking framework has been learned, there is the additional overhead of creating fake objects, setting up and running the tests and none of this would ever mean that I don’t go ahead and test it in the interface anyway.
    My present employer is the first with whom I’ve used such a framework and though this testing issue isn’t the only issue, were now running the risk of getting nothing done and this (along with the dreaded code review process) is a major component in our current failure.
    I’m going to have to leave because after 21 months, nothing saleable has been produced.

  2.   DeborahK — July 1, 2014 @ 10:56 am    Reply

    Hi Alan –

    Sorry to hear that your experience with testing has been frustrating and unproductive!

    I am not a proponent of mocking for mockings sake. I have not used mocking in any of the projects I have worked on. (And my last big project had well over 2200 unit tests.)

    I think that the concept of a “unit” has been taken too far, and has often lead to development focused too much on complex architectures instead of getting the work done and tested.

    I normally build the business objects/components/services first, and write unit tests to test them. I find that those tests save me TONS of time because I can get those pieces right before building the UI pieces.

  3.   Alan White — July 5, 2014 @ 1:33 am    Reply

    Thanks, Deborah. I agree with your outlook regarding mocking, though (unfortunately) it’s a necessary evil, particularly given the requirements of the current project, which is not just MVVM based (which is fine, IMO), but also entrenched in PRISM.
    A big issue with this is the way that the back end is being designed with a view to making it portable to either web or desktop clients, which means that the mechanism used is based on WCF.
    All this means that there’s is a level of abstraction that has the capability to drive oneself to distraction, with the creation of huge numbers of interfaces. In all my years in software development, I’ve never seen the need to code so many tests and indeed, nothing has ever gone wrong to an extent that could be justified by such disappearing-down-the-rabbit-hole testing.
    I even mentioned to my project leader that we’re at the point of checking that, having set the property int Number to 2, we are checking that we indeed set Number to the value of 2. I did mention this to the project manager, how said that, since it was as simple as that “it shouldn’t take too long to write the test, then”.
    My last employer was appalling, in terms of the way employees were treated by the owner, but software was being produced, because it needed to be and it was a small business that simply couldn’t have functioned without such things being done in a timely fashion.
    Really, (IMO, of course) many of these concepts are wonderful, if you work for an employer who has all the time and money in the world, but to a small business that wants to get things done, it’s the kiss of death.

RSS feed for comments on this post. TrackBack URI

Leave a comment

*

© 2014 Deborah's Developer MindScape   Provided by WPMU DEV -The WordPress Experts   Hosted by Microsoft MVPs