Agile Techniques and Tools. White Paper

Transcription

1 Agile Techniques and Tools White Paper

2 Agile Techniques and Tools Synopsis This section provides an overview of a number of techniques and tools that are commonly used by agile development teams. These tools and techniques are by no means restricted to agile development they can be used in other scenarios. Unit Testing & Test Driven Development (TDD) Unit testing very is important for agile projects probably more so than traditional waterfall projects. Complete (or close to complete) automated unit test coverage is required to ensure that delivered code is of a high quality. However unit testing alone is not sufficient to ensure a system meets requirements and quality targets integration and functional testing, and code reviews should also be used. Automated unit testing using tools such as NUnit is however recognized as an industry best practice. In an agile project automated unit testing is even more important as it is a pre-requisite to techniques such as refactoring. There are a number of ways that unit testing can be adopted: Test Last the code is written and then unit tests are written to confirm the behaviour Test First a set of tests are written / documented before a subset of the code is implemented. To get the tests to compile, stub / empty classes are written then the classes are implemented TDD again the tests are implemented first but the distinction is that the tests are used as a means of driving out the design of the system and are implemented iteratively. This is often referred to as Red-Green-Refactor Behaviour Driven Development (BDD) this is an evolution of TDD with even more of an emphasis on tests as specifications, matching tests to feature definitions There are a number of benefits to implementing unit tests before writing the code itself, either Test First or using TDD. In particular it ensures that unit tests are actually written. The danger with writing unit test after the code has been cut, is that time pressures will cause the developer to skip writing the tests or to not achieve full coverage. This is particularly the case if the developer leaves it too long and implements too much code before considering the unit testing. However with developer discipline and ensuring that only small chunks of code are written before considering unit tests this approach is still viable. A further benefit of implementing the unit tests first is that it encourages the developer to consider testability in the design, including techniques such as dependency injection that can make implementing unit tests much simpler. If the developer implements a large chunk of the system without considering unit tests when he finally puts his mind to unit testing it is likely to much more painful and unsuccessful. At this level (Test First / Test Last / naïve TDD) which technique is used is arguably just a technical issue for the development team / developer. It is not a central part of the design methodology. However if TDD is adopted fully in the spirit of the technique, then unit testing becomes a more core feature of the methodology. TDD advocates argue that TDD can be used to drive the design of the system as well as providing documentation for the system. At this level TDD becomes a core part of the methodology, rather than just a development technique. 2

3 It is this distinction that drove the development of BDD which is an evolution of TDD that takes this even further with an emphasis of linking tests to executable specifications. Both advanced TDD and BDD can be considered (mini-) methodologies, or at least can be used as the core component of a methodology. Taking aside TDD and BDD as components of a methodology, there are a number of factors which need to be considered when implementing unit tests: What level of unit tests should be implemented? Should tests be true unit tests at the class level or are higher level pseudo integration tests acceptable? Should tests be state-based or interaction based? When should each approach be adopted? How should techniques such as mocking frameworks be used? How should database interaction be handled in tests? Should the pure unit-tests attempt to use a fake implementation? Or should the unit tests be pseudo integration tests against the database? How are tests integrated into the build process? How are the UI components tested? Should patterns such as Model View Presenter (MVP) or Model View Controller (MVC) be used to increase test coverage? Should a tool such as Watin be used to automate tests through the UI? How should test coverage be measured? What are the targets for test coverage? Refactoring At some level refactoring is almost a pre-requisite for agile development. If a system is implemented in short iterations, with each iteration providing a minimal implementation to address the most critical features selected at the start of the implementation, then it has to be accepted that later iterations may require earlier work to be refactored / reworked. Otherwise the implementation can hardly be considered agile. Refactoring can be taken to encompass any re-working of previous implementations. However it is also used to refer to a lower level technique of refactoring at the microscopic level improving the implementation of one or more classes by applying standard re-factorings [Fowler] such as Extract Interface which are designed to address certain code-smells. There are a number of refactoring tools for.net that can be used to assist in refactoring including Resharper and RefactorPro in particular. Visual Studio.NET even includes a few basic refactorings out of the box. However refactoring as a whole is important for agile projects. In this context there are a number of issues to consider: It is important at a project level that the need for refactoring is acknowledged and indeed actively encouraged. If not then time-scales may force developers to skip refactoring (and the project will eventually suffer for it) As mentioned refactoring can be used to ensure that a clean design for the system emerges through development 3

4 Refactoring should be included in design reviews / code reviews reviews can determine targets for refactoring. This should be included explicitly in the process that is adopted time should set aside for it Refactoring can also be driven by TDD this is referred to as Red Green Refactor Repeat. Red = write a test that fails, Green = write the code to enable the test to pass, Refactor = refactor the code that has just been written. Wash and repeat! Continuous Integration Continuous Integration (CI) is also an important technique that should be considered as part of an agile project (or any other project for that matter). CI is a development practice where developers integrate their work on a frequent basis, at least daily, with the integration verified by an automated build process which normally also includes automated execution of the unit test suites to determine whether the build has been completed successfully. There are a number of CI tools available most notably the open source project CruiseControl.NET, but also a number of commercial tools such as FinalBuilder. These tools typically integrate with the source control system and can be setup so that a build is initiated whenever a check-in is completed by a developer. However it is also possible for the tools to be configured to perform builds on a schedule such a nightly. Code / Design Reviews The importance of code and design reviews cannot be underestimated, as they provide a perfect opportunity to tie many threads together. A design/code review should include: Review of the design of individual features Roles and responsibilities of classes Coding standards Unit testing techniques and coverage Determining any scope for refactoring Review of the build integration Domain Driven Design / Domain Models Domain Driven Design and the Domain Model pattern are important design techniques that are particularly suited to more complex applications. Both DDD and the Domain Model pattern focus on developing an implementation model that is close to the domain model of the end users, using the expressiveness of OO design to model the domain. In many ways both DDD and the Domain Model patterns are embodiments of classic OO techniques, though perhaps without some of the naivety of early OO modelling techniques. DDD also focuses on principles such as the Ubiquitous Language where the emphasis is on using a common language in all aspects of the project. The ubiquitous language is used in all communications, both with end users, between developers and project managers and also between 4

5 developers. Furthermore the terms of the ubiquitous language are reflected in the implementation model itself they are a core part of the model. DDD also focuses on model driven development though the emphasis is on expressing the model directly in the implementation. NOTE: Despite the similarity in terms this is not synonymous with Model Driven Architecture (which focuses on defining the application in UML and using this to generate the core of the implementation) and DDD does not imply development of a large UML model. DDD focuses on implementing a rich model in the code, with a close relationship to the domain model, providing the ability to refactor the model using techniques such as TDD. Furthermore, DDD recommends a number of useful design patterns including: Entity, Value Object, Aggregate, Repository, Factory, and Layered Architecture. Many of these are similar to standard patterns but are combined into a specific pattern language. Whilst overall the full DDD methodology is best suited to large applications with complex domains and largish teams, many of the concepts are useful to consider in the context of an agile project. In particular, the Ubiquitous Language is a strong concept that serves to promote clear communication and bring different views together. Expressing the business domain closely in the code, and refactoring as required, also serves to promote agility. The DDD / Domain Model approach is often approached more from a domain model first perspective and not from a Data Driven approach typically advocated by Microsoft s RAD tools (and other tools). In a data driven approach, the development starts by defining a database schema, which is then used to generate an entity model (or even to generate Typed Datasets). One of the advantages of the Data Driven approach is that it provides a lower barrier to getting early proto-types working. Defining a database model and then using this to build a few screens is a relatively easy way of getting a deliverable in the hands of the users. It is also typically an easier approach in terms of skill required by the developer. DB Consulting Thames Court 1 Victoria Street Windsor SL4 1YB T: +44 (0) E: nhill@dbgroup.co.uk 5