Maintainable: Code should be organized and extensible so that modifications are easy to make. It should be easy to update and maintain the code.
I am on a customer engagement at this very moment where maintainability is a big problem. We are tasked with updating code with bug fixes and new features. Unfortunately, in order to make one change, we have to affect five different projects and multiple files in each project. The maintenance costs associated with this application are very high. This is when you advocate for refactoring (i.e. rewriting) code for maintainability.
Testable: Code should be structured to support testability. This includes abstracting external dependencies so that code can be isolated for testing. Examples of external dependencies include databases and Web services.
One of the most common ways for isolating code for testability is to use interface development to abstract away your dependencies. Then, during testing, you can use dependency injection to provide an alternative implementation that relies only on local resources.
Tools and frameworks such as Microsoft Fakes, JustMock from Telerik, NMock, Rhino Mocks, and Moq help abstract away external resources that your application depends on by providing fakes, stubs and shims.
Now you need to write tests that that exercise your code. So what tests should you write? We advocate a lot for unit testing with code coverage analysis. This is the easiest type of test a developer can create. Unit testing needs to be integrated with both your IDE and Continuous Integration server. If done properly, you will see significant gains in quality and productivity.
A friend of mine once asked me for a review of a library used throughout our company. During the review I had suggested a significant change to his code. He agreed that it was a good change. A half-hour later, he sent out an e-mail to all of IT stating that a new version of the library was available in our NuGet repository. I said, “What, are you crazy?”
He said, “…But I have 100% code coverage, dozens of unit tests and all my unit tests passed.” He was confident that his new code would “just work.”
You might not be able to achieve 100% code coverage for your applications. In fact, most projects cannot achieve that amount of code coverage. The general rule in the industry seems to be around 80% to 85% code coverage, but even these numbers are sometimes hard to achieve. I would be concerned with any project that had less than 70% code coverage.