Solid Unit Testing
All developers want to build good quality software but not all developers test their software as they go along. Why not? A common explanation is "I don't have time to write tests!". The more pressure they feel, the fewer tests they write. This leads to less accurate and stable code, less productivity, less confidence and, ultimately, more pressure. It's a vicious cycle. This two-day course is designed to help you break out of the cycle by embracing unit-testing and, in particular, test-driven development. We will introduce the techniques and the tools necessary to prove your code as you go along.
Modules in Solid Unit Testing:
Introduction to Unit Testing
Using unit testing comprehensively within software development is a growing movement. Unit testing allows refactoring and maintenance with the confidence that existing functionality is not broken. In this module we will look at techniques for writing good unit tests and integrating them into testing frameworks to automate the tests. We will see that using the tests to drive the development guides you to produce flexible, loosely-coupled code with high test coverage.
Design for testing
Code is not inherently testable; it must be designed that way. In this module we look at common issues in code that make it hard to test and how we resolve them. Along the way we will look at Dependency Injection and Inversion of Control containers.
Testing Doubles and Mocking
The code that you want to test - the system under test (SUT) - will often have dependencies on other code that you don't want to test. For example, the SUT might be part of your business layer but it, in turn, relies on code in your data access layer. If your code is well designed then "test doubles" can be introduced into the SUT as "stand-ins" for the dependent code you do not want to test. A test double needs to do just enough to guarantee the correct behaviour of the SUT and no more. There are a variety of types of test double, such as stubs, mocks, dummies, fakes and spies. This module will discuss the appropriate usage of the different kinds of test double and show how a framework such as RhinoMocks and Moq can be used to introduce them. It also talks about various techniques of "dependency injection" by which test doubles can be introduce
Behaviour Driven Development is an 'extension' of Test Driven Development'. In BDD the tests are described with a specific syntax ('Given-When-Then') that can be written by developers, BAs or even end users. This can be done either directly through code or my using a DSL such as Gherkin and then parsing the code into an executable. One such tool for doing this in the .Net space is SpecFlow. SpecFlow lets you write BDD tests in Gherkin syntax, parses those into underlying NUnit tests and then lets you execute those tests in the NUnit runner of choice. BDD is typically (although not exclusively) used to drive 'end-to'end' testing of the system, to that end the tests will need to drive the user interface using tools such as Selenium
Introduction to Selenium
Many, perhaps most, software applications today are written as web-based applications to be run in an Internet browser. The effectiveness of testing these applications varies widely among companies and organizations. In an era of highly interactive and responsive software processes where many organizations are using some form of Agile methodology, test automation is frequently becoming a requirement for software projects. Test automation is often the answer. Test automation means using a software tool to run repeatable tests against the application to be tested. For regression testing this provides that responsiveness. During this talk we will demonstrate how we can use Selenium to automate the testing of browser based applications.
Having learn't about test driven development, now is the time to put it all into practice. In pairs you will be given an unseen coding challenge, you will use your newly acquired test driven development skills to provide a solution to the challenge. A prize will be given to the team who have solved the problem with the best set of unit tests.