What is it?
A collection of rules stating what a block of code should look like. These may include rules on where line breaks are required, how to place parentheses, how much whitespace to put before and after those parentheses, how many spaces to use when indenting and where to insert empty lines.
Read more…
It’s only a few days ago since we released the first version of Fluent Assertions, and we already have a new release. The reason for this is that the first release was just the public release of an internal set of classes that we’ve been using for a year or so. But this week, we've worked hard to add some important missing features that we really needed, and also improve resilience against illegal arguments such as an empty collection or null. Release 1.1 includes the following improvements.
- All dependencies on MSTest assemblies have been removed. So assertions will work with all testing frameworks.
- Added support for Silverlight
- Improved the verification messages around assertion of collections so that you don't need any debugging to figure out what went wrong.
- Added object.Should().BeAssignableTo()
- Added object.Should().Satisfy() to verify against a lambda or delegate.
- Added extension methods on an Action or Action<T> which allows better support for the AAA syntax. We've rewritten a large portion of the framework's unit tests and it definitely improves unit test maintenance.
- Added a ValueOf property to the exception assertions syntax that allows chaining additional Should()s on the properties of the exception.
You can download it here. The documentation can be found here.
In essence, Test Driven Development (TDD) is a practice in which the interface and the behavior of a component is designed while writing a unit test. In other words, you typically start writing a test case and define the exact members, behavior and names on the fly. In fact, the word Test in TDD is misleading at the least, because the whole practice is really a design methodology that promotes creating testable loosely coupled software. And since this is going to be a difficult endeavor without applying the right design principles, you usually end up with a maintainable and extensible system which by incidence also includes a high code coverage. Without TDD, these same goals are very difficult to reach.
Read more…
What is it?
A formal review of all code and artifacts related to a requirement or task by another person than the original developer. Rework because of review comments must be revalidated afterwards.
Why would you do that?
- Because the average developer
- introduces 10-50 bugs per 1000 lines of code (at least, according to Moore’s Law)
- is not always aware of the potential pitfalls of particular code constructs (hence coding guidelines)
- is not always up to date with all available constructs in a new C# version
- does not have full awareness of all the out-of-box solutions offered by the .NET Framework, open-source sites or commercial vendors
- often does not realize that an ingenious and elegant solution may be too complex to understand by others.
- sometimes loses sight of the overall solution and the initial goal when working on a some piece of code too long.
- Because it helps improve the awareness of, and the understanding behind your company’s coding guidelines.
Notice that the amount of necessary review work can be reduced by introducing the Pair Programming practice.
What’s the bare minimum you need to do?
- Find issues in the interpretation of the functional requirements.
- To verify compliance against your coding guidelines or standards.
- If you don’t have one, consider the Aviva Solutions C# 3.0 Coding Guidelines. Notice that these are an extension to Visual Studio’s Code Analysis, so the latter is still worthwhile.
- To find any loose ends such as TODOs or incomplete code. Resharper 4.5 includes a nice tool window that quickly shows an overview of all TODOs in your current solution. Resharper 5.0 even includes solution-wide analysis that finds dead code.
- To ensure that all code is easy to read and understand. For instance, all members and types have a comprehensive name and non-trivial code is annotated with code comments.
- To ensure that each and every check-in improves the code base, rather than introducing software rot.
What’s the usual thing to do?
- To ensure that all naming of code elements matches those of the functional design, preferably using Domain Driven Design’s Ubiquitous Language.
- To check for the usual pitfalls such as God classes or methods that are way too long.
- To find any redundant code or code that is unnecessarily complex and requires refactoring.
- To find any code constructs that may put other developers on the wrong foot and therefore jeopardize future maintenance.
- To find code constructs that can be replaced with a simple call to a previously developed generic class or .NET Framework construct.
- To stimulate the use of design principles such as S.O.L.I.D. or the design patterns defined by the likes of Martin Fowler and Eric Gamma so that the overall code quality increases.
How do you do that?
- It is important to make sure that all files related to a particular piece of functionality can be easily found. Use a Check-in Policy to associate each and every change with a corresponding work item such as a Scenario, Task or Bug. Since a major change may involve multiple check-ins, especially in a larger team where multiple developers work in the same areas of your code base, Change Sets provide insufficient traceability.
- Use a logging form or something similar to review every piece of code related to a particular work item and store it on the project’s team site.
- Alternatively, copy and paste the code into Microsoft Word, and use its reviewing features to annotate the code with comments and improvements.
- Or even better, install TeamReview and its corresponding Review Response work item and add review comments directly from inside Visual Studio’s code editor, while keeping them together under the associated work item. Also check-out this poster illustrating the underlying review workflow.
As part of my many assignments, I’m compiling a bunch of best practices into a set of development guidelines for bootstrapping our internal projects using TFS. I’ve decided to share these with the community so that others may benefit from it as well. Beware that these practices are not new nor in any way invented by myself. I'm merely trying to get some good resources together in a nice compact format.
So what are my goals?
- To provide insight into the benefits of applying well known best practices on software development projects.
- To provide examples of applying those practices on new and ongoing projects and explain how to gain the most of out them.
- To help you jumpstart a new project or professionalize running projects.
And what do you gain?
The goal of these posts is to end up with a set of development practices that provide the following benefits:
- Allows you to more quickly and accurately assess the impact of new requirements.
- Promotes building well designed software that allows changing functionality with lesser risks (even during a running project).
- Promotes a consistent code-base that solves similar problems using similar solutions, everywhere.
- Strives for a functionally consistent software system. For instance, ensuring that date fields look the same all over the application).
- Attempts to prevent code duplication so that you never have to make changes at multiple locations if you change a particular piece of behavior or logic.
- Eases the effort for deploying a new release by removing as many human actions as possible.
- Provides traceability on where a particular piece of functionality has been realized technically.
- Improves the developer experience when working on an existing or shared code-base (e.g. readability, purpose and goal of a block of code).
- Provides a safety net that reduces and possible prevents the chance of running into regression problems.
- Attempts to prevent common mistakes or misinterpretations by introducing common rules and recommendations.
- Strives to a situation where each and every member of the team is aware of the project’s affairs.
- Promotes any endeavors that improve the self-education and self-organization of teams.