NMock and TDD

I’ve always been an advocate for TDD although I think it is an uphill battle. I haven’t given up on having my group adopting TDD but I wish they were using it more and more.

Today I was writing some unit testing in a object model that had many dependencies and I notice the amount of Cra*(#$(. objects (fakes) I had to have in order to test a simple functionality.

Although I use unity to inject these instances it was still a bunch of static classes that didn’t do much. This monolithic approach was hard to change or adapt for different situations.

This situation made me leave my comfort zone and do some research with NMock. I have to tell you… I was hitting my head on my desk thinking why I did not use this before….

So I will spend some time talk about NMock and how you can benefit from using it in conjunction with TDD.

NMock 2.0

NMock is a dynamic mock object library for .NET. Mock objects make it easier to test single components—often single classes—without relying on real implementations of all of the other components. This means we can test just one class, rather than a whole tree of objects, and can pinpoint bugs much more clearly. Mock objects are often used during Test Driven Development.

A dynamic mock object:

• takes on the interface of another object, allowing it to be substituted for a real one for testing purposes.
• allows expectations to be defined, specifying how the class under test is expected to interact with the mock.
• fails the test if any of the expectations are violated.
• can also act as a stub, allowing the test to specify objects to be returned from mocked methods.

The best way to be Impressed is by Example

The scenario is a PermissionSystem that relies in a authenticated user with certain Permissions to access a resource. You want to test if a specific user can access the resource. The resource can be public, private or semi-private. For simplicity we will only present the following rules and we will only test a simple path:

• A public resource
  • Anonymous user cannot post
  • Authenticated user can Post
• Private Resource
  • Anonymous user cannot post
  • Authenticated can only post if it belongs to a role

The code presented is not functional only an example how you can setup expectations in your mocks in order to simulate scenarios.

The IUser interface

   1: interface IUser

   2: {

   3:     long Id {get; set;}

   4:     bool IsAuthenticated {get; set; }

   5: }

The Permission Service Interface

   1: public interface IPermissionService

   2: {

   3:     bool CanPerformTask(IContext context, long cid, string permission, string resource);

   4:     bool IsUserInRole(IRole role, IResource resource);

}

The main service would look like this (not really but .. you got the idea)

   1: public class PostService

   2: {

   3:     public PostService( IUser user, IPermissionService service )

   4:     {

   5:         ...

   6:     }

   7:  

   8:     public void Post( object post, IResource resource )

   9:     {

  10:         if( !user.IsAuthenticated )

  11:         {

  12:             throw new ApplicationException("User cannot post");

  13:         }

  14:         else if( resource.UserAccess == UserAccess.Public )

  15:         {

  16:             Post();

  17:         } 

  18:         else if( resource.UserAccess == UserAccess.Private )

  19:         {

  20:             if( service.IsUserInRole( "Authorized" )

  21:             {

  22:                 Post();

  23:             }

  24:             else

  25:             {

  26:                 throw new ApplicationException("User cannot post");

  27:             }

  28:         }

  29:     }

  30: }

The intent of the test is to verify if the behavior of Post method is correct when a user is authenticated but does not belong to the Authorized role.

   1:  [TestMethod()]

   2:          [ExcpetionException( typeof(ApplicationException))]

   3:          public void TryPostWithAuthenticatedUserUserNotInAuthorized()

   4:          {

   5:              Mockery mocks = new Mockery();

   6:              IUser loggedUser = mocks.NewMock<IUser>();

   7:              IPermissionService permissionService = mocks.NewMock<IPermissionService>();

   8:              IResource resource = mocks.NewMock<IResource>();

   9:   

  10:              Expect.Once.On(loggedUser)

  11:                     .GetProperty("IsAuthenticated")

  12:                      .Will(Return.Value(true));

  13:   

  14:              Expect.Once.On(permissionService)

  15:                  .Method("IsUserInRole")

  16:                  .WithAnyArgument()

  17:                  .Will(Return.Value(false));

  18:   

  19:              Expect.Once.On(resource)

  20:                     .GetProperty("UserAccess")

  21:                      .Will(Return.Value(UserAccess.Private));

  22:              PostService postService = new PostService(loggedUser, permissionService);

  23:              postService.Post(post, resource);

  24:   

  25:          }

• line 5 we are creating the mock factory if you will. This object will be responsible for creating dynamic proxies for your interfaces.


• Lines 6,7 and 8 . You are creating dynamic mock objects that mirror your interfaces.


• The next step is to set expectations. When you code by intent expectations are very clear. For this test you expect the user to be authenticated and also that he is in a specific role called Authorized. In addition you want the resource to be private.





• On the first example you are saying if the property IsAuthenticated is called in my mock return true.



• On the second statement you are saying if the Method IsUserRole is called in my mock permission service with any argument return false.



• And if the resource.UserAccess property is called return private.

Interesting in this construction is that your unit test not only tests the behavior of the method post but also the expectations or how post should relate to dependent objects. When you state Expect.Once.On you are saying that post method should only call this method or property once. If that rule is broken your unit test will fail.

At the end of the test you can still verify if all expectations were met. Ex. If IsUserInRole is not called at all you have a problem. Your test will fail.

Better than that. By changing one expectation you can test a totally different aspect of the Post method. Ex. Make IsUserInRole return true.

Here is a cheat sheet for Nmock that will get you going.

Conclusion

Programmers working with the test-driven development (TDD) method make use of mock objects when writing software. Mock objects meet the interface requirements of, and stand in for, more complex real ones; thus they allow programmers to write and unit-test functionality in one area without actually calling complex underlying or collaborating classes^[6]. Using mock objects allows developers to focus their tests on the behavior of the system under test (SUT) without worrying about its dependencies. For example, testing a complex algorithm based on multiple objects being in particular states can be clearly expressed using mock objects in place of real objects.

Apart from complexity issues and the benefits gained from this separation of concerns, there are practical speed issues involved. Developing a realistic piece of software using TDD may easily involve several hundred unit tests. If many of these induce communication with databases, web services and other out-of-process or networked systems, then the suite of unit tests will quickly become too slow to be run regularly. This in turn leads to bad habits and a reluctance by the developer to maintain the basic tenets of TDD.

When mock objects are replaced by real ones then the end-to-end functionality will need further testing. These will be integration tests rather than unit tests.

If before you were able to write tests first and then code; now with Mocks things are much easier. You can start defining your interfaces and quickly you can write tests that reflects the intentions for the class you are testing.

By using mocks the creation process become more organic since you don’t need to have every single implementation of your interfaces in place in order to start testing and coding. You can always isolate the subject of tests and play around with your mocks.

Code Standard and its benefits

It is a fact of life -- developers like to write code in different styles. Show us code written by ten different developers and we can show you ten different coding styles. So why should we try to develop and enforce coding standards? – Nigel Cheshire and Richard Sharpe

Motivation

This week after coming back from vacation and reviewing some code I notice that although we, as a company, advocate code standards people still value “the so called speed” for code clarity and style.

That motivated me to write about the importance of code standard and the benefits the group gains if everyone adhered to it.

Introduction

Believe or not I still remember the time we programmed C in Unix and the pride we would take in knowing that we were the only ones to understand our own code (at least understand while we were working on it). Variables with obscure names (a1, c4, etc) added to the mystic of being a computer scientist.

Nowadays with the improvement of internet, communication, collaboration and other buzzwords that implies working together; code standards became a necessity; a tool to improve communication. The value is no longer in the mystic but code in such an elegant way that the code communicates.

So, why code standards? Code standards are important for many reasons. First and foremost, they specify a common format for source code and comments. This allows developers to easily share code, and the ideas expressed within the code and comments, between each other. Most importantly, a well designed standard will also detail how certain code should be written, not just how it look on screen.

More important than the reasons for having a standard is actually adhering to it consistently.  Having a coding standard documented and available means nothing if developers are not using it consistently.  If that becomes the case, it is no longer a coding standard, it has become a coding suggestion.  Worse yet are the developers that do not have a style or standard at all, and think that their lack of a style/standard IS a coding style/standard!

Style vs. Standard

It is important to differentiate between a style of coding and a standard. A code style specifies things like how you indent, tabs vs. spaces, use of “Hungarian” notation of names and variables, etc. A standard often includes a coding style, but goes beyond just hot to name a variable: it tells you how that variable should be treated and when it should (and should not be) used.

So it is clear that creating a standard is no easy task. Good news is that for us .NET programmers, the standard already exists and tools to enforce these standards are part of the Develop environment we use.

• StyleCop - StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project.
• FxCop or Microsoft code Analyses -FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements. Many of the issues concern violations of the programming and design rules set forth in the Design Guidelines for Class Library Developers, which are the Microsoft guidelines for writing robust and easily maintainable code by using the .NET Framework.

These tools tend to be a pain, initially, when the programmer has so many bad habits that he/she will spend more time fixing their mistakes than coding. But as you become familiar to the standard you start to create good habits and program to the standard.

I personally tend to create snippets, little tools that helps me even more to code to the standard. Nowadays I know exactly what StyleCop will complain if I do wrong.

So what are the benefits you gain by adhering to a standard?

Benefits for Developers

• The source code will be more comprehensive and will become more easy-to-maintain. As the programmers become familiar to the standard and use the supporting tools more and more they tend to program to the standard and produce better code.
• The uniform approach for solving problems will be handy because code standards documents reveal recommended methods that were tried and tested on early projects.
• Less communication between developers and managers will be needed because programmers will not ask anymore on the details of the specification document because the defaults are stated in the standard.
• Is common to the less experience programmer to re-invent the wheel. When there are coding standards, there is a big chance that particular problem is not really a new problem, but in fact, a solution may be documented before.

Benefits for the Quality Assurance Team

• Well documented coding standards will aid the creation of "Test Scripts". Having reviewed the source code and tested an application based on compliance to coding standards, it added strong direction to ensure quality of the software product.
• Of course the readability of code improves QA understanding of functionality what improves the creation of automation or test scripts.

Benefits for Program Managers

• It is important for the project managers to maintain and secure source code quality on their projects. Implementing coding standards could jumpstart this goal halfway to its realization.
• Repeated performance pitfalls could be avoided. It is a common case that a released software product could be less impressive when it comes to performance when the real data has been loaded in the new developed database application.
• Lesser man-hour consumption as the sum of all efforts implementing coding standards.

Adhering to Code Standard

As shown above adhering to a well designed code standard can give your software development an edge. The hard part is convincing developers to adhere to it. Often we hear from developers that adhering to a standard slows them down, the tool is too restrictive, standards take the “creativity” out of programming, etc.

It is understandable that in crunch time you could argue that. It is understandable but not excusable. Tools and techniques are out there to facilitate such techniques. Not adhering to it shows the lack of commitment and the desire to improve.

While I am not going to describe the various methods that can be used to achieve this goal, I will mention one: Accountability.

Accountability will generally cause developers to write better code.  If they wrote a bug, they should fix it.  If the bug would have been prevented by adhering to the standard, it should be brought to their attention.  The flip side of this is that they should be rewarded for writing good code.

The secret to code to a standard is to constantly use stylecop or other tools. You may be impacted initially but it will payoff for you and your team later.

Conclusion

Coding standards are being adopted by more and more development organizations. Estimates suggest that 80% of the total cost of a piece of software goes into maintenance, and not enough effort is being directed at ensuring that the quality is maintained during the development process. Further, development and Quality Assurance teams are spending too much time in code reviews, correcting coding standards violations that could be detected and in some cases corrected automatically.

Tool for code analyses and coding style are out there to help achieve this goals. The challenge is not in the technology but in educating developers on the benefits of adhering to it.