UnitOfWork

I want to talk more about testing software.

Through my professional career and my work in Aalborg .NET User Group, through my participation at conferences and by reading blogs, articles and books, it has become evident to me, that the importance of testing software is lost on a large percentage of developers and businesses.

If not lost, then at least not well understood and therefore not prioritized on the basis of entirely misconstrued economical reasons. It is a fallacy that by not spending money on testing, you save money. The exact opposite is the case.

In this post and several others, I will try to sum up, what I think, I know about testing software in a broad and generalized sense. To the professional software test engineer, everything in this post and the next ones is old news, but to many developers the content will be new ground and it will show that testing software is more complicated and nuanced than they thought.

Why spend time and money on testing software?

In today's world, software is the glue that binds almost everything. There is software in our watches, phones, cars, laptops, music systems, airplanes, trains, televisions - places we take it for granted. But software is quickly making its way into less obvious places such as kitchen appliances: microwaves, freezers, coolers, coffee makers and food processors to name a few. We monitor our sleeping babies with wireless network devices that are stuffed with software. In hospitals almost everything has embedded software and you can be pretty sure that your country's infrastructure and airspace is monitored by software programs. The list just goes on and on. And we haven't even mentioned the vast majority of businesses, that are completely dependent upon their ERP systems, data analysis programs and office packages.

We are all almost entirely dependent upon software that works. Not all software works. Why? Well, as this series of articles will reveal, the reasons are many, but mainly because those involved with its creation are fallible creatures - humans.

This is unfortunate for us. Why? Because untested software will kill you! Or at the very least make your life miserable...

Untested software will kill you slowly by increasing your daily stress level. We all know the irritation of waiting for unresponsive programs. We all know the anger felt when our word processing program crashes and we loose our work. We all know the increasing pressure in our chest and the throbbing in our temples when we spend an inordinate time trying to use bug ridden, monolithic governmental software systems that are supposed to make it all so easy for us. Over time it adds up.

Untested software will kill you quickly as when the airplane you are in drops out of the sky. Or when the paramedics cannot be called due to overloaded telephone systems. Or when early warning systems fail to detect the mega wave that just passed the software embedded buoy. And so on and so on.

Untested software will kill your business because dissatisfied (or dead) customers won't ask for your services again.

Untested software is expensive. We all know this. Here in Denmark we have many government software projects that have failed miserably, not solely due to lacking software testing, but certainly as a big part of it. Trying to repair such systems will only increase the magnitude of its failure.

Fixing bugs in an untested software system of any moderate or high complexity is a daunting and difficult task. Fixing bugs in an untested software system of any moderate or high complexity that was not written with testability in mind is an impossible task. Well, maybe not for the very best senior elite developers, but the rest of us are screwed. So we start looking for jobs elsewhere...

To sum it up. We want to spend time and money on testing software because:

• we are dependent on it
• those who write it are fallible
• not testing it will kill people
• not testing it will kill business
• not testing it will make the developers look for job elsewhere
  
• it is more expensive not to

Labels: Testing, Tests

This post is just so I don't forget... :)

We develop BDD style and run several dozen tests during the day. While NUnit is a great test suite, it is somewhat cumbersome to switch out of Visual Studio every time you need to run a test. But we use ReSharper extensively and it integrates a test suite (using NUnit under the covers) into VS itself that is much more friction free to use.



You can click the green/yellow icon on the break point line that denotes a test and choose to run the test from the menu that pops up.

While this is a great feature you can take it a step further and bind the run test command to a keyboard binding.

1. Go into Tools > Options > Keyboard.
2. Write "ReSharper.UnitTest_ContextRun" in the "Show commands containing" field or scroll down and locate it in the list.
3. Select the "ReSharper.UnitTest_ContextRun" in the list and set the shortcut for the selected command to "Alt+X" (or any other combination you prefer).
4. Click OK.

Now you can run test from almost any context. You have the following options:

1. Place the mouse curser in a test method and press "Alt+X"
2. Select a class in the Solution Explorer and press "Alt+X" (runs all tests in the class)
3. Select a folder in a project and press "Alt+X" (runs all tests in folder)
   
4. Select a project in the Solution Explorer and press "Alt+X" (runs all tests in project)
5. Select the solution in the Solution Explorer and press "Alt+X" (runs all tests in solution)
   

Labels: Tests, Tools