Here is a presentation I did on an overview of the three main practices under the Agile umbrella, Scrum, XP, and Lean. PPTX available upon request.

http://testdrivendeveloper.com/content/binary/Agile%20Software%20Development%20Overview.pdf

We've all used teardown methods in our test classes, right? It's a good way to clean up after the tests run. But wait - what do we need to clean up? Data in a database probably? Well, that would mean that the database hasn't been mocked out... making it not really a unit test... Unit tests should run really, really fast. If we haven't mocked out just about all of the dependencies (like databases, service calls, etc.) then the tests are not only dependent on external systems, but they are going to run slow also. Slow running tests tend not to get run as often, and don't provide us the rapid feedback we need in order to have the confidence that our code is working correctly.

Every time we encounter a test class with a tear-down method, we should take a hard look at what is being cleaned up in the teardown, and why that is necessary. Can we refactor the tests so that teardown is not needed? Can we mock out that database so there isn't any data to clean up? Can we mock out those expensive objects we had to construct and then deconstruct? Is there a way to make the tests run faster?

Remember, refactoring is the last (and most forgotten) step of TDD... Take a look at the test code too - not just the main line code. Look at the code as a whole, from a variety of perspectives. If we have to clean up something afterward, then something in the test might just be dirty... The focus of the unit tests is really to test just the code under test, and not other objects or systems, so always try to isolate it and eliminate other variable by mocking as much as possible.

Ever see a call in code like this?

      connection.Close();

Watch out - Close() or Dispose() calls are a code smell! In .NET, we have lots of classes that implement the IDisposable interface (like most of the ADO SQL connection classes) and registry access, and lots more. It's pretty common for most of the whole framework I think. Whenever a class does implement IDisposable, it has to provide a Dispose() method which should clean up anything in memory, and tie up loose ends.

The safest thing we can do with these kinds of objects, is to wrap them in a using() block. This way the Dispose() method gets called no matter what happens, even if there is some kind of exception thrown. It's guaranteed. The using() structure is superior to and much cleaner than coding up a try/catch/finally, and much easier to read.

Example:

            using (SqlConnection conn = new SqlConnection(connectionString))
            {
                conn.Open();
                using (SqlCommand cmd = conn.CreateCommand())
                {
                    cmd.CommandType = CommandType.StoredProcedure;
                    cmd.CommandText = "dbo.sp_Sproc";
                    cmd.Parameters.Add(new SqlParameter("@parm1", "foo"));
                    cmd.Parameters.Add(new SqlParameter("@parm2", "bar"));
                    cmd.Parameters.Add(new SqlParameter("@id", id));
                    string xml = (string)cmd.ExecuteScalar();

                    // ...
                }
            }

If you can safely refactor the code (it has tests), take out the explicit calls to Close() or Dispose(), and refactor to use a using block. Make sure to check if a class implements IDisposable, and use a using block whenever possible.

Do you know the three parts of each and every test? Arrange, Act, Assert (also known as setup, test, validation). Each test should have these three sections, and they should always come in this order. Many non-unit tests should have an additional step also - Cleanup. I have found on many teams that the first step - Setup - is often either missing or incomplete. The purpose of testing is to create an environment around the code under test [CUT] and hold it steady so that it is in a known state. We need to control all of the variables except for the ones we are actually testing. If we allow multiple things to vary in a test, we can have varied results and intermittent failures.

We can't trust intermittent tests... so always identify the three sections on your tests, and make sure that the Setup section is sufficient to keep all the variables in a steady state except the ones under actual test.

As Esther Derby's article discusses, it's the area of integration testing or cross-context testing where we most often discover the discrepancies in interfacing systems to each other. Automated acceptance testing, or automated integration tests are a key point for winning the bug battle in larger systems. If the teams and/or organizations negotiate a contract on test automation across these integration points, they can collaborate to create test frameworks and test automation that can be used to ensure proper functionality. These acceptance tests (or end-to-end tests as some call them) can and should be demonstrated to key stakeholders to make sure that the business understands what development is delivering, and that it meets the intended need.

As I often say, if we have automated acceptance tests, we can do ATDD: First, we automate the acceptance test, which fails because there is no code yet to test. Then, we write unit tests and code, more unit tests, and more code - striving ONLY to make the acceptance test pass. We should focus on just the one failing acceptance test, and not stray off into other functionality. Once we do, we can refactor to make sure we have the best solution, then we start all over again with writing more automated acceptance tests. That's ATDD!

Test automation is such a great thing to have on a project. It makes me smile each time an automated test catches a bug that would have otherwise gone unnoticed and perhaps even shipped to production.

This will be my last article for 2011, hope you had a great year! Best wishes for a fantastic 2012!

Lately I have been doing work on WinForms applications and have been looking at ways to test them. We use unit tests to test at the method level, and [ideally] our code is written to be able to separate the logic code from the UI code. However, not *all* applications are written this way (unfortunately). Today I am in a situation where I must be able to test an application at the UI level. I need to bring up forms, type in text boxes, poke buttons, and inspect results in labels, etc.

The answer is NUnitForms! This fabulous test framework is an open source project that extends the functionality of NUnit, and allows us to test applications at the UI level. We don't consider this to be a unit test or even integration test mechanism, but rather a functional test mechanism. Rather than having testers manually go through screen after screen in the application just to see if it all works, we'll write some NUnit code that will automate it all for us.

So How do I do it?

SourceForge bits: http://sourceforge.net/projects/nunitforms/files/nunitforms/

First, download the NUnitForms source code and add it to your solution. Then, write an NUnit test class, add a reference to the NUnitForms project and make your test class inherit from the NUnitFormsTest class. Add a reference to your application classes, and create a test. In the test, open your form with Form.Show() (so that it is visible). Then use a ButtonTester, a LabelTester, TextBoxTester, etc. to find each of the controls by name, and do the appropriate action to them. Then, after all of your actions are completed, call Application.DoEvents() to make sure to let everything have time to execute. You can then grab those text boxes, labels, etc. and Assert that the values are correct. That's it! Build it up step by step, and you have a fully automated end-to-end test!

If your forms are simple enough, you might even be able to use the Recorder application that comes with the codebase to record your keystroke and mouse actions as a C# code test. If your app has some startup code to accomplish, refactor it so that it's in simple methods, and include a hidden form in the app that your Recorder can open to accomplish the startup before opening other forms.

I have written and included sample code in a Visual Studio 2010 project in the zip file attached. This is a really great way to automate acceptance, functional, and end-to-end tests for a WinForms application project.


Updated NUnitForms code Here (5.8MB) includes NAnt and NUnit also
Sample code Here (5.5MB)

Why would a stakeholder want to care about refactoring. It only makes development take longer, which means they get fewer features delivered. In some places it's a hard-sell. These are the situations where we find a lot of "Red, Green, Done" code written. Sometimes it's just Green, Done and even Done, Green. Let's examine why and how refactoring could be of interest to a stakeholder.

• Stakeholders shouldn't know or care if a developer is writing unit tests, main-line code, or refactoring something.
• It's not their job, it's the developer's job. There needs to be trust, and it goes both ways.
• The stakeholders should be focused more on business strategy and how features and information can help the company make more money.
• If they are that involved with development tasks they are either micromanaging or just nosey.
• Not that there shouldn't be transparency - there should. But people should focus on their area of expertise and let everyone else do their jobs too.
  
• Refactoring improves the code. Here are but a few reasons to do it.
  
• More robust - fewer issues
  
• Faster - more performant
  
• Easier to change, requiring less training
  
• Easier to understand the logic
  
• Less easy to write bugs
• Code operation is more stable
  
• Cheaper/faster to maintain
• Cleaner and simpler
• Refactoring the design clarifies intent and makes testing easier
• Clear code tracks more closely and obviously with business requirements
• Refactoring sometimes makes bugs obvious and they can be eliminated in development rather than after test phases.
  
• We can map these advantages to direct dollar savings in development
• Most bugs can be tracked to code that is obtuse, complex, or convoluted.
• Many studies have been done that show bugs are much less costly to eliminate in the earliest phases, design and development.
• Not writing bugs is far less expensive than finding them and fixing them.

Truly informed stakeholders will not only accept refactoring, they will encourage it, because the practice actually saves time and money in the long AND short-run.