There is also an interesting implication to this, it means that the traditional order, design -> code -> test, is switch around so we test -> code-> design (refactor) when we do TDD.

This often is interpreted as: “I am not allowed to do any upfront design at all.” This notion actually contains two fallacies about TDD:

• First, TDD is not like Extreme Programing where either you are doing it or you are not. TDD is Fuzzier with room for doing things in different ways, so it fits both your style of work and the project you are doing.
• Second, the purpose of TDD is to control the gap between the point at which you do something and the point at which you figure out if that something actually works. If you do a bit of design and then immediately write a test that essentially is the first user of that design then I don’t see a problem with that.

Where you might start to get in trouble is if you try and combine TDD with big upfront design, where you map out all the classes and all their interactions. When you do that then the gap between the design and the code which uses that design becomes too big.

If we jump back to the test -> code -> design, I mentioned earlier, in truth that is actually a little too simple. Since this is not a linear process, it is circular. What it actually looks like is this:

Therefore, if you want to start with doing a bit of design upfront, all you are really doing is starting your first cycle at the refactor step, instead of the test step. Considering you will do several 100s to 1000s cycles though this before any larger project is done, I doubt anybody we hold it against you if you started that first on out at the “wrong” place in the process.

The design you do before you start should not be set in stone. It is very likely to change before you are done. Think of it as a direction to drive in, not a turn by turn map instruction to get to the goal.

When I first started writing code, I would have begun by writing the Circle class as shown below.

Circle.java

public class Circle
{
    private int radius;

    public Circle(int radius)
    {
        this.radius = radius;
    }

    public double getArea()
    {
        return 3.14 * this.radius * this.radius;
    }

    public double getCircumference()
    {
        return 2 * 3.14 * this.radius;
    }
}

Next, I would have written a main class to instantiate and execute the methods of my new class.

Main.java

public class Main
{
    public static void main(String... args)
    {
        Circle cirlce = new Circle(5);

        System.out.println("Area: " + System.out.println(circle.getArea());
        System.out.println("Circumference: " + System.out.println(circle.getCircumference());
    }
}

When I was sure that my class worked the way that I wanted, I would have started on my next class. Depending on the circumstance, when I was finished developing my application, I would have deleted the main class or modified the main class to execute the program.

This approach proved problematic when working on a large web application. I would either pick a place in code that I could easily trigger from an unrelated user interface and test the new code much the same way as shown above, or I would develop the new feature from the top down, executing the new code from the user interface at periodic intervals to make sure my code was working as expected. Of course, the latter approach required that the user interface be in place.

This is a horrible approach, and this problem was the first to show me the practicality of unit testing. Unit testing allows you to isolate the code you are writing and independently execute the code outside the scope of the entire application.

With unit testing, starting new development is as simple as starting to write tests. In the case of the Circle class, I begin by writing the basic structure of the class.

Basic Circle.java

public class Circle
{
    public Circle(int radius)
    {
        
    }
}

I realize that I have written the skeleton of my class before writing my test. This does not conform to test-driven development, but I like to take this initial step so I don’t get errors or warnings in my IDE. I am now free to start writing my tests using JUnit.

I know that if the radius of the circle is negative, I want to throw an IllegalArgumentException. I first write the test that asserts that we expect an error when instantiating a Circle with a negative radius.

TestCircle.java

@Test(expected = IllegalArgumentException.class)
public void testCircle()
{
    Circle circle = new Circle(-1);
}

Of course, this test will fail, but I am now free to continue developing my Circle class outside of the scope of the application

Implementing the constructor in Circle.java

public class Circle
{
    private int radius;

    public Circle(int radius)
    {
        if(radius < 0)
        {
            throw new IllegalArgumentException("A circle's radius cannot be less than zero.");
        }

        this.radius = radius;
    }
}

Now this test will pass, and I can move on to developing more of the Circle class.

To drive this point home, let’s consider that we are developing the General Geometry Calculator. This calculator will be a web application that allows users to calculate various geometrical properties of shapes. With unit testing, I don’t have to have the user interface designed and implemented, and I don’t even have to start my development server. I can simply start working on the Circle class and use it when I am ready.

I hope I have demonstrated how developing code in isolation is beneficial. I don’t think isolating code development is the most important benefit of unit testing, but it is the first practical aspect of unit testing that I experienced. It allows a developer to construct various parts of an application independently without regard to other areas of the application. Part two of this series will describe how unit testing forces developers to analyze their code more closely.

• http://blog.virtew.com/2012/08/18/setup-teamcity-on-an-azure-virtual-machine-for-windows-8-metro-style-apps/

I promptly set about creating a configuration that would run all my unit tests, but ran into a small problem when it came to the JavaScript side of things.

I’d designed my test project to re-use the bundle config from my web app, and then used MVC to render the test runner. I thought I had been very clever… I had the benefit of picking up new source files as and when I created them; no need to constantly add references to new scripts in the test project.

When I came to run these tests as part of my TeamCity build process however, I realised that I needed to compile and host my tests in order to run them… not something that is easily achieveable as part of a normal build process. We don’t always know where our code will be checked out to, and we may need to do this in a way that will work for multiple configurations.

Not to worry though, with a bit of coding, we can make this work.

The requirements

Our chain of events needs to run as follows:

• Build the test project
• Start IIS Express to host the tests
• Run the tests and capture the results
• Shut down IIS Express

Seems simple enough. Dan Merino has a great post on how to use the jasmine team city reporter in conjunction with Phantom.JS to run our tests and process the results:

• http://blog.danmerino.com/continuos-integration-ci-for-javascript-jasmine-and-teamcity/

It’s also pretty easy to run IIS express from the command line (of course you’ll need to have iis express installed on your build server first):

• http://www.iis.net/learn/extensions/using-iis-express/running-iis-express-from-the-command-line

Where it all comes unstuck however, is that we need to start IIS express after we’ve built our code, but before running our tests. Then we need to stop it again after our tests have run. There’s no built in way to do this with team city however, we need to script this in some way or write an app to help us.

Phantom Express
First we need to configure a runner in our test project that will output the results in a form that TeamCity can interpret, we can do this using the TeamCity reporter:

<html>
<head>
    <title>Jasmine Spec Runner</title>

    <link rel="shortcut icon" type="image/png" href="/Content/jasmine/jasmine_favicon.png">
    <link rel="stylesheet" type="text/css" href="/Content/jasmine/jasmine.css">

    @Html.Partial("TestIncludes");

    <script type="text/javascript">
        (function () {

            var jasmineEnv = jasmine.getEnv();
            jasmineEnv.updateInterval = 1000;

            var teamCityReporter = new jasmine.TeamcityReporter();

            jasmineEnv.addReporter(teamCityReporter);
            var currentWindowOnload = window.onload;

            window.onload = function () {
                if (currentWindowOnload) {
                    currentWindowOnload();
                }
                execJasmine();
            };

            function execJasmine() {
                jasmineEnv.execute();
            }

        })();
    </script>

</head>

<body>
</body>
</html>

Secondly, we need a control file for phantom.js that will load our runner. Here’s one based on Dan’s example that will run our tests and pipe the console output:

    console.log('Loading a web page');
    var page = new WebPage();
    var url = "http://localhost:8080/tests/teamcityrunner";
    phantom.viewportSize = {width: 800, height: 600};

    //This is required because PhantomJS sandboxes the website and it does not show up the console messages form that page by default
    page.onConsoleMessage = function (msg) { console.log(msg); };

    //Open the website
    page.open(url, function (status) {

        //Page is loaded!
        if (status !== 'success') {
            console.log('Unable to load the address!');
        } else {
            //Using a delay to make sure the JavaScript is executed in the browser
            window.setTimeout(function () {
                page.render("output.png");
                phantom.exit();
            }, 1000);
        }
    });

I wrote a quick command line app that will do the rest for us. All we need to do is supply it with the location of the iisexpress executable, the test site root, port, location of phantomjs and the control js file. Just make sure that you provide an appropriate timeout in the control.js file so that your tests have time to run before phantom.js closes.

I’ve copied the code for the console app into a gist as it was too long to post here: https://gist.github.com/Roysvork/5274142, you just need to compile this and copy it to your build server.

Finally, here’s a snapshot of the resulting configuration in Team City:

Now when we run our build, phantom express will fire up iis express, run our tests and voila!

Now you can utilise all the benefits of MVC (or any other aspect of .net) to include files and specs for your Javascript unit test suite and render your test runner. Not bad!

Pete

References:

• http://www.jetbrains.com/teamcity/
• http://blog.virtew.com/2012/08/18/setup-teamcity-on-an-azure-virtual-machine-for-windows-8-metro-style-apps/
  
• http://blog.danmerino.com/continuos-integration-ci-for-javascript-jasmine-and-teamcity/
• http://www.iis.net/learn/extensions/using-iis-express/running-iis-express-from-the-command-line
• https://gist.github.com/Roysvork/5274142

The scenario is simple.

I have an Item entity, and I have ItemService. The service provides functionality to add an item and to retrieve it. That’s about it.

In unit test, for one reason or another, one might decide to clean up, or DELETE some item. However, in this case, I would very much like to keep my service layer clean, i.e. just because I happen to need a clean up on the test-side, I should not force my service to implement it. Perhaps another way to look at it is that this is my way to reduce coupling. The user of the service should knows about the service, and the service should not know about where it is being used. One direction, so to speak.

So, to start with, here’s the code:

ItemDistributionServiceTest

package com.dwuysan.service;

import com.dwuysan.entity.Item;
import com.dwuysan.util.EntityManagerProducer;
import javax.inject.Inject;
import javax.persistence.EntityManager;
import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.shrinkwrap.api.ArchivePaths;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;

/**
 * @author denywuy
 */
@RunWith(Arquillian.class)
public class ItemDistributionServiceTest {

    private Item item;
    @Inject
    private ItemService itemService;
    @Inject
    private EntityManager em;

    @Deployment
    public static JavaArchive createTestArchive() {
        return ShrinkWrap.create(JavaArchive.class)
                .addClass(Item.class)
                .addClass(ItemService.class)
                .addClass(EntityManagerProducer.class)
                .addAsManifestResource("test-persistence.xml", ArchivePaths.create("persistence.xml"))
                .addAsManifestResource("META-INF/beans.xml", ArchivePaths.create("beans.xml"))
                .addAsResource("ValidationMessages.properties");
    }

    @Before
    public void setup() {
        this.item = new Item();
        item.setCode("item01");
        item.setName("item01");
        item.setUom("piece");

        this.item = this.itemService.getItem(this.itemService.createItem(item));
    }

    @After
    public void cleanUp() throws Exception {
        this.em.remove(em.merge(this.item));
    }

    @Test
    public void testDistribute() throws Exception {
        /*
         * Test omitted
         */
    }
}

So, to DELETE the item, I directly use EntityManager#remove(...). However, that results in the following error:

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.847 sec <<< FAILURE!
testDistribute(com.dwuysan.service.ItemDistributionServiceTest)  Time elapsed: 0.625 sec  <<< ERROR!
javax.persistence.TransactionRequiredException
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.doTxRequiredCheck(EntityManagerWrapper.java:163)
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.doTransactionScopedTxCheck(EntityManagerWrapper.java:145)
	at com.sun.enterprise.container.common.impl.EntityManagerWrapper.merge(EntityManagerWrapper.java:280)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

same as above

After further reading, I found that we need to explicitly initiates transaction. So, the code change slightly to:

ItemDistributionServiceTest

package com.dwuysan.service;

// the rest of the imports go here
import javax.annotation.Resource;
import javax.transaction.UserTransaction;

@RunWith(Arquillian.class)
public class ItemDistributionServiceTest {

    private Item item;

    // the rest of the injections go here
    @Resource
    private UserTransaction utx;

    @Deployment
    public static JavaArchive createTestArchive() {
        // same as above
    }

    @Before
    public void setup() {
        // same as above
    }

    @After
    public void cleanUp() throws Exception {
        utx.begin();
        this.em.remove(em.merge(this.item));
        utx.commit();
    }

    @Test
    public void testDistribute() throws Exception {
        /*
         * Test omitted
         */
    }
}

Reference:

Kosi2801, 2009, EntityManager throws TransactionRequiredException on merge() in JBoss JSF bean, accessed 29 March 2013.

Three key features for SharePoint developers were the focus of my session:

Unit testing SharePoint

Most SharePoint developers I know don’t write unit tests. It’s just too hard to isolate your custom logic from SharePoint. Without unit tests, developers must spend a lot of time setting up environments, inserting test data, and walking through numerous pages to see if their code is working as intended.

Visual Studio 2012 Update 1 adds a SharePoint emulation capability based on the Fakes Framework. You can now write unit tests against your code without even having a live instance of SharePoint! You can even alter the behavior of the SharePoint API to control what the API returns to you.

This feature requires Visual Studio Premium and Update 1.

Performance and load testing SharePoint

Any time you are writing code, its always good to keep in mind performance implications. Users get frustrated when applications aren’t responsive. Unfortunately, SharePoint is such a dynamic system, that it could be hard to create usable web performance tests in earlier versions of Visual Studio. With sites, lists, and documents all having unique identifiers that varied across environments, these tests would require a lot of manual revisions to the recorded URL’s. There was also a lot of extra “noise” in the HTTP traffic.

It never fails that when users need something in SharePoint, a LOT of them also need it – at the same time. So, load testing is also important in SharePoint. They’ll sometimes make a problem worse by retrying their last action because they aren’t sure its working properly.

Update 1 adds features to make the recording of web performance tests ignore the noise and identify any SharePoint error pages encountered. The dynamic parameter detection has been extended to extract and pass the unique identifiers for SharePoint objects like site names, list GUIDs, document names, and more.

This feature requires Visual Studio Ultimate and Update 1.

Advanced debugging SharePoint with IntelliTrace

Do you support issues reported by your SharePoint users? Ever wonder what to do with those correlation IDs you see on a SharePoint error page? Its not always easy to reproduce issues within SharePoint.

This update makes it very easy to take advantage of IntelliTrace in order to see what lines of your code executed leading up to the reported issue. Even though the error didn’t occur in your development environment, IntelliTrace will log all of the activity so you can play it back in Visual Studio – even if you don’t have the source code on your machine! You can also filter to specific correlation IDs within the IntelliTrace log.

This feature requires Visual Studio Ultimate and Update 1.

You can download the slides for our sessions from my SkyDrive here. Most of my demo’s were based on the hands-on labs here (and get the associated VM here).

Are you a SharePoint developer? Are these new features interesting to you? Let me know what you think.

I was recently TDD’ing some new code here at MoneyVista and wanted to assert that the expression passed to an IRepository method was correct.  This was a key test as changing the expression in the future would fundamentally change the behaviour of the SUT.  Other than the normal benefits of TDD I wanted to ensure that anyone changing the expression in the future would have to do so with good reason, as they would also then need to fix a failing unit test.

I’ve FooBar’d the classes of interest from the MoneyVista code base – so I hope it still makes sense.

First up we have our IRepository which just exposes a FindAll<T> method.

public interface IRepository
{
  IQueryable<T> FindAll<T>(Expression<Func<T, bool>> expression ) where T : IDomainObject;
}

Next we have a Queue obejct whose responsibility is to find all BarFoo objects with a status of New, map to FooBar objects and return. The Queue uses an instance of IRepository and IMapper (which is a simple wrapper around the normally static AutoMapper so that I can inject it as a dependency to the Queue).

public class Queue
{
  /*
  fields and ctor()
  */

  public IEnumerable<FooBar> GetNewFooBars()
  {
    var fooBars = new List<FooBar>();

    foreach (var barFoo in _repository.FindAll<BarFoo>(x => x.Status == BarFooStatus.New))
    {
      fooBars.Add(_mapper.Map<BarFoo, FooBar>(barFoo));
    }

    return fooBars;
  }
}

Using Moq we can test that the expression “x => x.Status == BarFooStatus.New” is passed to IRepository as follows.

[TestClass]
public class QueueTests
{
  private Mock<IRepository> _repository;
  private Mock<IMapper> _mapper;
  private Queue _queue;

  [TestInitialize]
  public void TestInitialize()
  {
    _repository = new Mock<IRepository>();
    _mapper = new Mock<IMapper>();
    _queue = new Queue(_repository.Object, _mapper.Object);
  }

  [TestMethod]
  public void GetNewFooBars_FindsNewBarFoosOnly()
  {
    // Arrange
    Expression<Func<BarFoo, bool>> expectedExpression = x => x.Status == BarFooStatus.New;
    Expression<Func<BarFoo, bool>> actualExpression = null;

    _repository.Setup(x => x.FindAll(It.IsAny<Expression<Func<BarFoo, bool>>>()))
      .Callback((Expression<Func<BarFoo, bool>> x) => actualExpression = x)
      .Returns(new List<BarFoo>().AsQueryable());

    // Act
    _queue.GetNewFooBars();

    // Assert
    Assert.AreEqual(expectedExpression.ToString(), actualExpression.ToString());
  }
 }

Using Moq’s Callback method to store the actual expresion passed to the mock works great – the only caveat to mention is that the assert is based on the string representation of the expressions, so if Queue changed to “y => y.Status == BarFooStatus.New” the test would fail. This is something that I can live with in order to get the testing benefit.

I got the job despite my lack of unit testing knowledge. The initial several months of my development career involved fixing bugs in legacy code.  There were no unit tests, the code was heavily coupled, and it was just really, really hard to maintain.  With my head deep in legacy code, I still didn’t have much exposure to unit testing.  We eventually decided to refactor as much of the code as possible, and this is where I really progressed in my knowledge of unit testing.

In the following several years, I have come to realize the practical benefits of unit testing.  I strive to make sure developers on my project check in code that has close to 100% test coverage, and that they understand the utility of this practice.   I have noticed that many developers fail to realize the benefits of writing tests, regardless of their experience.

This will be a multi-part series on unit testing, and I will give examples of how and why to unit test.  The examples will be written in Java using JUnit and Easymock, but I think that the essence of the posts will be applicable to any application and programming language.

I am by no means the authority on unit testing, so if you have anything to add, I would love for you to comment on the posts.  The only thing I ask is that it not devolve into pedantry.

Part 1 – Isolates Development
Part 2 – Encourages Analysis
Part 3 – Facilitates Refactoring

Try it like this:

using NUnit.Framework;
using System.Transactions;
namespace ProjectName.Tests.Integration
{
 [TestFixture]
 public class TestClass
 {
 private TransactionScope _transactionScope;
 [SetUp]
 public void SetUp()
 {
 _transactionScope = new TransactionScope(TransactionScopeOption.RequiresNew);
 }
 //...Test some stuff, insert records, update records, etc...
 [TearDown]
 public void TearDown()
 {
 _transactionScope.Dispose();
 }
 }
}

Happy Testing,

Jim

While quality professionals have always needed to test combinations of code, current methods for writing and combining code have changed so much that traditional approaches to testing can’t get the job done at the right price and the right time.  There is a fast growing commercial market for production services that are incorporated as self-contained modules into software applications. Third party services such as PayPal or a credit checking service are increasingly used in customer facing applications.

Use of these third-party services increases the efficiency of software development, but at the same time makes your application dependent on services that you do not control. Consider, for example, the scenario of an online retailer with multiple suppliers. The retailer has created a new mobile application for customers.  This application uses a credit check service provided by a third-party vendor. The team can’t test without this dependent component, but it is not available for testing. Without service virtualization, the software development team has some difficult choices to make and none of the options are good. If the development team proceeds without doing the necessary testing, they may introduce errors that are much harder and more costly to fix later on. If the team waits until the third-party service is available, developer productivity will decline and the team may miss production deadlines. In addition, if the third-party service becomes available it can get pretty expensive to test application performance at high usage levels since the service costs money each time it is executed.

So what does the development team do in this situation? Service virtualization is a new approach to testing that helps organizations eliminate some of the testing bottlenecks that make it hard to bring new high quality applications to market quickly. Here are five key things you should know about service virtualization.

1. To get started with service virtualization you need to understand your testing methodology and think about where service virtualization can increase team velocity while also helping your team to deliver higher quality software.
2. Use a cost/benefit analysis to select which services should be virtualized.  Consider the cost to your company when testing is delayed because dependent services or software are not available for testing. How much is spent on staff needed to set up and maintain test environments? How much do you spend to maintain test environments that are not fully utilized? What is the cost for software licenses in the physical test lab environment? What is the cost of third-party service access fees?
3. Service virtualization can help you find errors in all testing phases- including unit testing, performance testing, integration testing, system testing, system integration testing, user acceptance testing, and operability testing.
4. Recording a service that already exists is a great way to define the behavior of your virtual component. You can use the recording process to identify the behaviors that will need to be simulated so you can create test cases quickly.
5. You can’t expect to virtualize all your components. Therefore, you need to be able to easily move back and forth between real components and virtual components while you are testing. You want to maintain consistency across real and virtual components.

One of the biggest impacts of service virtualization for developers is the ability to validate integrations much earlier in the application life cycle. The software development team can move beyond unit testing and overcome many of the roadblocks that inhibit timely, efficient, and cost effective testing.

However, since I kind of overwrote my existing Python installation (OS X 10.6) with the version from Macports, my easy_install and pip were still pointing toward one of my older Python installations. Ergo, pyrg wouldn’t run. After researching for a while I came across this excellent post on Stack Overflow, and followed the instructions to uninstall my easy_install and then reinstall using the distribute package mentioned on there, followed by reinstalling pip.

This by itself didn’t do anything, and I had to make sure in my shell’s rc file that the Macport version of Python was in the path before other, regular places like /usr/local/bin, etc. That fixed it. Run with $ pyrg python_file or $ python python_file |& pyrg. Colors can be easily customized as well. Hooray for going from the colorless test run output on the left to a proper visual feedback on the right!

Colorful with pyrg

Colorless without pyrg

This is my first time using unit testing tool because in my previous job, a lack of documentation on system workflow always prevented me to create well defined test cases and its expected results. Here, the new developer has done excellent job on documenting the workflow and made my job is easier (I am using version 2.6.1 on Visual Studio 2010 on Windows 8, btw).

And then come first obstacle after installation. I encountered error alert box popped up when I try to load my DLL project file into newly created NUnit project. The error said: “This assembly was not build by any known testing framework“. After minutes of browsing on stackoverflow and couples of forum, it turned out that I need to go to the Tools -> Settings -> IDE Support -> Visual Studio and check the option: “Enable Visual Studio support” as indicated in figure below:

After that, you can load the DLL file to NUnit project. However, at this moment, I confused because it turned out the graphical appearance for my project is quite different from the sample project in the bundled NUnit software. The sample project has a look of apparently some classes together with its methods and a set of test cases to be executed upon clicking ‘Run’ button at the main interface:

In contrast, my DLL project did not have tick and cross icons and no public methods which were defined inside those DLL project were visible from this NUnit GUI screen. It turned out that we need to incorporate NUnit library (nunit.framework.dll) located inside bin folder of NUnit program into our Visual Studio project. You can right click and choose ‘Add reference…’ in Solution Explorer window and browse that DLL file inside NUnit installation path.

After that you can test your methods which are contained inside code behind file. First, just add NUnit.Framework namespace and then use [TestCase] statement above the methods which you want to test as shown below:

After that, I compiled my class library project and then I reopened the NUnit project and viola, the test is working now:

 __block MyViewController *viewController = nil;
                
 beforeAll(^{ // Occurs once
 });
                
 afterAll(^{ // Occurs once
 });
                
 beforeEach(^{
   viewController = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:nil];
   // Lazy loading of the UIView's
   __unused UIView *aView = viewController.view;
 });
                
 afterEach(^{
   viewController = nil;
 });
                
 it(@"should not be nil", ^{
   [viewController shouldNotBeNil];
 });
                
 it(@"should have the IBOutlets not nilled", ^{                            
   // The description's Label IBOutlet
   UILabel *descriptionLabel = (UILabel *)[viewController objectForPropertyName:@"descriptionLabel"];
   [descriptionLabel shouldNotBeNil];
 });

 it(@"should respond to the IBActions", ^{
   // This Button should have an action
   NSNumber *actionMethod = @([viewController respondsToSelector:@selector(anAction:)]);
   [[actionMethod should] beTrue];
 });

Don’t forget that with this you are only able to see that the IBAction exist and the UIViewController responds to it… Not that the your Xib’s element is connect to it.

public class TestBase
{
	public static string GetCaller()
	{
		StackTrace stackTrace = new StackTrace();
		return stackTrace.GetFrame(2).GetMethod().Name;
	}

	public void IsPending()
	{
		Console.WriteLine("{0} -- pending", GetCaller());
	}

	public void Describes(string description)
	{
		Console.WriteLine("-----------------------");
		Console.WriteLine(description);
		Console.WriteLine("-----------------------");
	}
}

These are not the only available tools but they are amongst the most popular.

You can find today’s slides here.

You can find some example code here

You should also check out papers on testing, JUnit and JMock such as

• Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes, “Mock Roles, Not Objects”, OOPSLA 2004

All source code can be found on GitHub here.

This post is part of my cheat sheet series.

// *** STUB ****
// A stub is an object which is required to pass the SUT.

mocks.CreateStub<T>(); 

// The simple stub
var sut = MockRepository.GenerateStub<ISimpleModel>();         
sut.Stub(x => x.Do()).Return(1);

// Stub Property
sut.Stub(x => x.AReadonlyPropery).Return(1); // Reaonly ( only get )
sut.AProperty = 2; // Stub Get

// Repeat
mock.Stub(x => x.Do()).Return(1).Repeat.Once();
mock.Stub(x => x.Do()).Return(2).Repeat.Twice();
mock.Stub(x => x.Do()).Return(3).Repeat.Times(3);

// Events
mock.Raise(x => x.Load += null, this, EventArgs.Empty);

// **** Arguments Conditional ****
// These can be used for Stub, Expect, AssertWasCalled and AssertWasNotCalled

// Ignore Arguments Conditional
sut.Stub(x => x.Do(Arg<int>.Is.Equal(1))).IgnoreArguments().Return(1);

// Is Conditionals
sut.Stub(x => x.Do(Arg<int>.Is.Anything)).Return(1);
sut.Stub(x => x.Do(Arg<int>.Is.Equal(1))).Return(1);
sut.Stub(x => x.Do(Arg<int>.Is.NotEqual(1))).Return(10);       
sut.Stub(x => x.DoIFoo(Arg<Foo>.Is.Null)).Return(1);
sut.Stub(x => x.DoIFoo(Arg<Foo>.Is.NotNull)).Return(2);
sut.Stub(x => x.Do(Arg<int>.Is.LessThanOrEqual(10))).Return(1);
sut.Stub(x => x.Do(Arg<int>.Is.GreaterThan(10))).Return(2);
sut.Stub(x => x.DoIFoo(Arg<Foo>.Is.Same(foo))).Return(1);
sut.Stub(x => x.DoIFoo(Arg<Foo>.Is.NotSame(foo))).Return(2);
sut.Stub(x => x.DoIFoo(Arg<Foo>.Is.TypeOf)).Return(1);      

// Matches Conditional
sut.Stub(x => x.Do(Arg<int>.Matches(y => y > 5))).Return(1);

// List Conditionals
sut.Stub(x => x.Do(Arg<List<int>>.List.Count(RIS.Equal(0)))).Return(0);
sut.Stub(x => x.Do(Arg<List<int>>.List.Element(0, RIS.Equal(1)))).Return(1);
sut.Stub(x => x.Do(Arg<List<int>>.List.Equal(new int[] { 4, 5, 6 }))).Return(2);
sut.Stub(x => x.Do(Arg<List<int>>.List.IsIn(1))).Return(1);
sut.Stub(x => x.Do(Arg<int>.List.OneOf(new int[] { 4, 5, 6 }))).Return(2);   

// ByRef and Out parameters 
sut.Stub(x => x.Do(Arg<int>.Is.Equal(1), ref Arg<int>.Ref(RIS.Equal(0), 10).Dummy)).Return(1);
sut.Stub(x => x.Do(Arg<int>.Is.Equal(1), Arg<string>.Is.Equal("Hello"), out Arg<int>.Out(10).Dummy)).Return(1);

// **** DYNAMIC MOCKS ***
// A mock is an object which we can set expectations on and will assert that those expectations have been 
// Dynamic Mock provides easier syntax and does not require stubbing/expecting all methods

mocks.CreateMock<T>(); 

// Assert Was Called
mock.AssertWasCalled(p => p.Add(Arg<AnotherModel>.Is.Anything));
mock.AssertWasCalled(p => p.Add(Arg<AnotherModel>.Is.NotNull));
mock.AssertWasCalled(p => p.Add(Arg<AnotherModel>.Is.Equal(theModel)));
mock.AssertWasNotCalled(p => p.Add(Arg<AnotherModel>.Is.Null));       
mock.AssertWasCalled(x => x.AReadonlyPropery);
mock.AssertWasCalled(x => x.AProperty);
mock.AssertWasCalled(x => x.AProperty = 9);
mock.AssertWasCalled(x => x.EventHandler += Arg<AnEvent>.Is.Anything); // Event was registered

// Expect & Verify
mock.Expect(p => p.Add(Arg<AnotherModel>.Is.Anything));
mock.Expect(p => p.Add(Arg<AnotherModel>.Is.NotNull));                    
mock.Expect(p => p.Add(Arg<AnotherModel>.Is.Equal(theModel)));
mock.Expect(x => x.AReadonlyPropery).Return(9);
mock.Expect(x => x.AProperty).Return(9);
mock.Expect(x => x.AProperty).SetPropertyAndIgnoreArgument();
mock.Expect(x => x.AProperty).SetPropertyWithArgument(11);

mock.VerifyAllExpectations()

This post is part of my Dot Net On Linux posts. All the source code is available on GitHub here

Intro

This post is just to point you to my HowTo on Rhino Mocks and also to make the code available as part of the .Net on Linux post series.

All source code can be found on GitHub here.

My cheat sheet in generics can be found here while some code examples in generics can be found in my post here.

This is part of my HowTo in .NET seriies. An overview can be seen here,

Intro

Rhino Mocks is a mocking framework for .Net. In essence a mocking framework allows you to stub a complex expensive resource such as a database or webserver. However mocking frameworks can allow you to completely isolate a SUT during testing. Mocking frameworks also allow the creation of expectations of methods calls between a mock and the SUT; the unit test will then fail if the expected method calls were not made or made but with the wrong parameter values. Testing can then be behavioural as well as state based. This how to looks at the syntax for version 3.6 and above which does not require the record and playback syntax.

Stubs

Stub A Method

The simplest explanation of when to stub is when a resource such as a database or web service is encountered; something which is expensive to consume when unit testing. Providing a stub for a class which consumes a database can allow us to substitute this at run time making unit testing quicker and easier but also it can allow us to very easily create complex unit tests with a wealth of data which is very easy to set up without having to create test data within a database. The following simple example mocks an interface called method called Do() on interface ISimpleModel which takes no parameters and when called returns 1 as an integer. MockRepository is used to create a fake or stubbed instance of ISimpleModel, it is upon this that we are required to call our functions. If we were stubbing a class and not an interface then one thing to note is that you would not get any functionality of the class. You can not mix and match functionality of the class and stubbed functions.

var sut = MockRepository.GenerateStub();
sut.Stub(x => x.Do()).Return(1);

Stub A Property

Get functions of properties can be stubbed. The following syntax allows stubbing of a readonly property (get only).

var sut = MockRepository.GenerateStub();
sut.Stub(x => x.AReadonlyPropery).Return(1);

The following syntax allows stubbing of a get method of a property.

var sut = MockRepository.GenerateStub();
sut.AProperty = 2;  // Stubs a Get_AProperty as 2
Assert.That(sut.AProperty.Equals(2));

It is not required to stub set methods. Any methods can be consumed automatically without stubbing them, only if we need a return value other than default(T) for value types and null for reference types do you need to stub the method. Set methods return void so stubbing this is not required.

Arguments

If our stubbed methods takes arguments then we need to provide for them.

Ignoring Arguments

In the simplest form we might not care what values the parameters take and can simply state that they can be anything. Allow the argument to be Anything.

sut.Stub(x => x.Do(Arg.Is.Anything)).Return(1);

Call IgnoreArguments() will make any constrained arguments parameters have their constraints ignored.

sut.Stub(x => x.Do(Arg.Is.Equal(1))).IgnoreArguments().Return(1);

Constrained Arguments

Constrained arguments allow us to return different data based upon the method parameter values which it is called upon. When all parameters are matched the return is made. If multiple stubs are matched then the first registered stub instance is used to determine the return value.

Is

Is constants provide predicates for literal and reference types. The following is a quick run through of the Is argument constraints. Equal and NotEqual for equality based comparison.

sut.Stub(x => x.Do(Arg.Is.Equal(1))).Return(1);
sut.Stub(x => x.Do(Arg.Is.NotEqual(1))).Return(10);

Comparison between two literals.

sut.Stub(x => x.Do(Arg.Is.GreaterThanOrEqual(10))).Return(1);
sut.Stub(x => x.Do(Arg.Is.GreaterThan(10))).Return(2);
sut.Stub(x => x.Do(Arg.Is.LessThanOrEqual(10))).Return(1);
sut.Stub(x => x.Do(Arg.Is.LessThan(10))).Return(2);

Comparison to null with Is.Null and Is.NotNull.

sut.Stub(x => x.DoIFoo(Arg.Is.Null)).Return(1);
sut.Stub(x => x.DoIFoo(Arg.Is.NotNull)).Return(2);

IsTypeOf to determine if the type is of the required type. In this example Moo and Foo both implement IFoo Whig is the parameter type. Based upon whether Foo or Moo is passed in we can alter our return value.

sut.Stub(x => x.DoIFoo(Arg.Is.TypeOf)).Return(1);
sut.Stub(x => x.DoIFoo(Arg.Is.TypeOf)).Return(2);

Identity comparison with Same and NotSame functions.

sut.Stub(x => x.DoIFoo(Arg.Is.Same(foo))).Return(1);
sut.Stub(x => x.DoIFoo(Arg.Is.NotSame(foo))).Return(2);

List

The List functions allow us to provide predicates upon elements which implement IEnumerable and IEnumerable. I aliased RIS as ‘using RIS = Rhino.Mocks.Constraints.Is;’ to make a distinction between NUnit and Rhino Mocks Is. The simplest form of List is the count which allows us to compare the element count against an Is constraint. Any of the Is constraints which predicate numbers can be used; Equal IsLessThan etc. Below we stub Do(IList t) twice once for when the parameter contains no elements and another for one element.

sut.Stub(x => x.Do(Arg>.List.Count(RIS.Equal(0)))).Return(0);
sut.Stub(x => x.Do(Arg>.List.Count(RIS.Equal(1)))).Return(1);

Element allows comparison of element at a position to an Is constraint. The first parameter is the element position and the second parameter is an Is constraint.

sut.Stub(x => x.Do(Arg>.List.Element(0, RIS.Equal(1)))).Return(1);
sut.Stub(x => x.Do(Arg>.List.Element(1, RIS.GreaterThanOrEqual(2)))).Return(2);

Equal allows comparison of a collection to another.

sut.Stub(x => x.Do(Arg>.List.Equal(new int[] { 1, 2, 3 }))).Return(1);
sut.Stub(x => x.Do(Arg>.List.Equal(new int[] { 4, 5, 6 }))).Return(2);

IsIn allow predicating if an element is contained within the collection.

sut.Stub(x => x.Do(Arg>.List.IsIn(1))).Return(1);
sut.Stub(x => x.Do(Arg>.List.IsIn(4))).Return(2);

OneOf allows predicate for any elements in both collections;

if one or more elements are found in both collections then the predicate is deemed as passed.

sut.Stub(x => x.Do(Arg.List.OneOf(new int[] { 1, 2, 3 }))).Return(1);
sut.Stub(x => x.Do(Arg.List.OneOf(new int[] { 4, 5, 6 }))).Return(2);

Matches

When the predicate is more complex or the built in functionality is not sufficient the Matches function provides more scope by taking a Predicate delegate; if you can write it you can predicate it!

sut.Stub(x => x.Do(Arg.Matches(y => y > 5))).Return(1);

Repeat

It is possible to set up the stubbing for x number of repetition; thus we can return different results dependant upon the call iteration. The methods Once(), Twice() and Times(int x) are provided.

mock = MockRepository.GenerateStub();
mock.Stub(x => x.Do()).Return(1).Repeat.Once();
mock.Stub(x => x.Do()).Return(2).Repeat.Twice();
mock.Stub(x => x.Do()).Return(3).Repeat.Times(3);

ByRef and Out Parameters

By Ref parameters can be implemented by utilising the ref keyword along with the Ref and Dummy methods.

sut.Stub(x => x.Do(Arg.Is.Equal(1), ref Arg.Ref(RIS.Equal(0), 10).Dummy)).Return(1);

Out parameters can be implemented by utilising the out keyword along with the Out and Dummy methods.

sut.Stub(x => x.Do(Arg.Is.Equal(1), Arg.Is.Equal("Hello"), out Arg.Out(10).Dummy)).Return(1);

By Literal

Though highly discouraged stubbing by literals can also be utilised.

sut.Stub(x => x.Do(1).Return(1);
sut.Stub(x => x.Do("Foo").Return(2);

Mocks

A Mock is similar to a Stub, in fact it contains all the functionality mentioned above however mocks can record required behaviour and fail a unit test if the required behaviour is not called upon by the SUT. For example If we have a class A which requires to call two methods on class B with certain parameters we can ensure that all of this behaviour is called or fail the unit test. We can either place expectation calls on the mock prior to the unit test act or we can make assertions of function calls during the assert.

Assert Was Called

AssertWasCalled provides a way asserting that a function call with required parameters was called. If a return value is required then this method can not be used.

Argument Constraints

All argument constraints mentioned previously in the stubs section can and should be utilised along with the AssertWasCalled function. If the function was not called with the parameter constraints then an exception is thrown and as such the unit test fails. The following example shows how to ensure that a function is called ignoring the parameter values.

[Test]
public void WhenArgumentsIsAnything()
{
	IModelRepository mock = MockRepository.GenerateMock();

 	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	modelCreator.CreateModel(theModel);

 	mock.AssertWasCalled(p => p.Add(Arg.Is.Anything));
 }

The following example shows how to ensure that a function is called ensuring that the parameter is not null.

[Test]
public void WhenArgumentsIsNotNull()
{
	IModelRepository mock = MockRepository.GenerateMock();

 	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	modelCreator.CreateModel(theModel);

 	mock.AssertWasCalled(p => p.Add(Arg.Is.NotNull));

 }

The following example shows how to ensure that a function is called ensuring that the parameter is equal to a reference type.

[Test]
public void WhenArgumentsIsEqual()
{
	IModelRepository mock = MockRepository.GenerateMock();

 	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	modelCreator.CreateModel(theModel);

 	mock.AssertWasCalled(p => p.Add(Arg.Is.Equal(theModel)));

 }

Assert Was Not Called

AssertWasNotCalled works exactly the same as AssertWasCalled however it throws an exception and fails the unit test if the method with argument constraints was called.

[Test]
public void WhenNotCalled()
{
	IModelRepository mock = MockRepository.GenerateMock();

 	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	modelCreator.CreateModel(theModel);

 	mock.AssertWasNotCalled(p => p.Add(Arg.Is.Null));

}

Properties

The syntax for asserting that a readonly property or get method of a property is exactly the same as each other (unlike when we look at Expect and Verify!).

[Test] public void WhenReadonlyProperty()
{
	var sut = MockRepository.GenerateMock();

 	var foo = sut.AReadonlyPropery;

 	Assert.That(foo.Equals(0));

 	sut.AssertWasCalled(x => x.AReadonlyPropery);

 }

[Test]
public void WhenProperyGetCalled()
{
	var sut = MockRepository.GenerateMock();

 	Assert.That(sut.AProperty, Is.EqualTo(0));

 	sut.AssertWasCalled(x => x.AProperty);

 }

Asserting that a set method of a property is called with a literal value.

[Test]
public void WhenProperySetCalled()
{
	var sut = MockRepository.GenerateMock();

 	sut.AProperty = 9;

 	Assert.That(sut.AProperty, Is.EqualTo(0));

 	sut.AssertWasCalled(x => x.AProperty = 9);

 }

Expect and Verify

Expect and Verify has two advantages over the AssertWasCalled style syntax. Firstly it allows stubbing inline with the Expect function call and secondly it allows setting the expectations as part of the assign stage along with other Stub functionality which might be required. The Expect() method allows all argument constraints as shown in the stub section above and works exactly the same as stub however if when VerifyAllExpectations is called as part of the assert section of the unit test any configured expects which have not been called or called with the required parameters, an exception is thrown and the unit test fails. Unlike AssertWasCalled syntax no equivalent functionality for AssertWasNotCalled is provided.

Argument Constraints

All argument constraints are available. Below are a few examples The following example shows how to ensure that a function when it does not matter what parameters are used.

[Test]
public void WhenArgumentIsAnything()
{
	IModelRepository mock = MockRepository.GenerateMock();

	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	mock.Expect(p => p.Add(Arg.Is.Anything));

 	modelCreator.CreateModel(theModel);

 	mock.VerifyAllExpectations();

 }

The following example shows how to ensure that a function only requires that the function is called without a reference type being null.

[Test]
public void WhenArgumentIsNotNull()
{
	IModelRepository mock = MockRepository.GenerateMock();

 	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	mock.Expect(p => p.Add(Arg.Is.NotNull));

 	modelCreator.CreateModel(theModel);

 	mock.VerifyAllExpectations();

 }

The following example shows how to ensure that a function with equality check for a reference type.

[Test] public void WhenArgumentIsEqualTo()
{
	IModelRepository mock = MockRepository.GenerateMock();

 	var modelCreator = new ModelCreator(mock);

 	var theModel = new AnotherModel() { FieldA = 1, FieldB = "Test" };

 	mock.Expect(p => p.Add(Arg.Is.Equal(theModel)));

 	modelCreator.CreateModel(theModel);

 	mock.VerifyAllExpectations();

 }

The following example shows how to ensure that a function is called with a number type parameter equal to 9.

[Test]
public void WhenReadonlyPropertyCalled()
{
	var sut = MockRepository.GenerateMock();

	sut.Expect(x => x.AReadonlyPropery).Return(9);

 	Assert.That(sut.AReadonlyPropery, Is.EqualTo(9));

 	sut.VerifyAllExpectations();
}

Properties

The first example shows how to place an expectation on a get method of a property.

[Test]
public void WhenPropertyGetCalled()
{
	var sut = MockRepository.GenerateMock();

 	sut.Expect(x => x.AProperty).Return(9);

 	Assert.That(sut.AProperty, Is.EqualTo(9));

 	sut.VerifyAllExpectations();

 }

This example shows how to place an expectation on a set method while ignoring the parameter value.

[Test]
public void WhenPropertySetCalledWithIgnoreArguments()
{
	var sut = MockRepository.GenerateMock();

 	sut.Expect(x => x.AProperty).SetPropertyAndIgnoreArgument();

 	sut.AProperty = 1;

 	sut.VerifyAllExpectations();

 }

This example shows how to place an expectation on a set method with an explicit value.

[Test]
public void WhenPropertySetCalledWithArguments()
{
	var sut = MockRepository.GenerateMock();

 	sut.Expect(x => x.AProperty).SetPropertyWithArgument(11);

 	sut.AProperty = 11;

 	sut.VerifyAllExpectations();
 }

People understand slightly different things when they hear the term ‘legacy code’. For some people…it is code that is no longer supported, for others – it is source code inherited from someone else or source code from an older version of the software.

Michael Feathers (Working Effectively with Legacy Code ISBN 0-13-117705-2) introduced what for me is a more insightful definition of legacy code – that speaks directly to the underlying problem that working with it creates. His definition of Legacy Code is “code without tests”. He goes on to say “Codes without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse”.

Because Agile Scrum can only deliver on its promise of ‘faster and better’ software if the continuous improvement feedback loops are timely and accurate…. transitioning legacy code into an Agile Scrum environment presents significant problems.

The special problem of legacy code is that it was never designed to be testable. It is often a huge convoluted mess of spaghetti code, where it is very difficult or downright impossible to isolate small parts to be unit tested. So before unit testing, you need to refactor the code to make it more testable.

However, in order to refactor safely, you must have unit tests to verify that you haven’t broken anything with your changes… This is the catch 22 of legacy code.

In order to break out of this catch 22 situation – there are a number of techniques that can be deployed so that you can start to insert good quality unit tests into your code. Good quality units tests are test that:

• Run very fast
• Help us localize problems.

When you start to introduce unit tests – you should expect to take a few backward steps. As you begin to break down the dependencies and introduce barriers into your code so that you can start to insert new unit tests…these changes to the code can often make the code initially ugly or more complex, but breaking dependencies is the medicine that will make the code better in the long run.

Generally, when we want to get tests in place, there are two reasons to break dependencies: sensing and separation

• Sensing – we break dependencies to sense when we can’t access values our code computes
• Separation – we break dependencies to separate when we can’t even get a piece of code into a test harness to run.

One of the biggest challenges in getting legacy code under test is breaking dependencies. When we are lucky, the dependencies are small and localized…. but more often than not…you are confronted with a mass of dependencies throughout the code base.

To address this problem, we need to find or introduce seams in our code. A seam is a place in the code where you can change the behavior of your program without modifying the code itself. If we can replace behavior at seams, we can selectively exclude dependencies in our tests. We can also run other code where those dependencies where if we want to sense conditions in the code and write tests against those conditions. Often this work will help you get just enough tests in place to support more aggressive or challenging changes.

This process of refactoring your code to make it ‘test friendly’ is a significant investment that your organization will have to make, but it is a prerequisite for successful Agile Scrum development. Great results from Agile Scrum require great feedback loops…. and those feedback loops depend on test friendly software…which by definition…. excludes Feathers’ definition of ‘legacy code’.

I think Mocking libraries, although very powerful, can enable developers to over complicate their unit tests. Unit tests should be short and easy to understand. I have lost count of the times where I have seen a developer mock out more than they need to because of excessive class coupling in their code. Just because you can mock out any object doesn’t mean that you should and avoid reducing excessive coupling.

I have also seen mocks being used by developers that abuse the layering and design of their solution. As an example, we have a 3rd part consultancy company writing some code for us to help augment our team numbers. Just recently myself and another group of leads were reviewing this consultancies code. They were developing a web service and on the face of it, were composing their code in layers. They had a service layer, calling a business logic layer, calling a data access layer. All sounding very familiar and normal at this point.

What we then found was they had huge amounts of business logic that had been put into the data access layer and not in the business logic layer. This raised quite a few alarm bells, so we looked at the tests. What we found was not nice. They had written a series of tests for the business logic layer that completely mocked out the data access layer. Normally this is fine as you don’t want to actually hit a database in a unit test, but what they had done was actually mock out the majority of their business logic which meant the tests were not doing anything useful at all.

Whilst I am picking on this one example, this is not the only case where I have seen mocking libraries used for evil.

So, what do I prefer instead. My own preference, and this is one I practice with my own team, is to write code to interfaces and use simple dependency injection to inject implementations into your code. By doing this instead I feel you have much more control over your code and your tests generally end up easier to write once you get used to this way of coding. I have written another post on simple dependency injection, so I recommend reading that.

In my team I have pretty much outlawed the use of mocking libraries on new or previously refactored and cleaned code, there just is no need to use them as we practice writing well designed code written to interfaces and following the SOLID principles.

SOLID is a set of design principles that every software developer who practices object oriented design should follow. If you follow these principles then you will find that you really don’t need to use mocking libraries (on new code at least, more on that later). The SOLID principles are:

S – Single responsibility principle. An object should have only a single responsibility.

O - Open/Closed principle. Objects should be open for extension, but closed for modification.

L – Liskov substitution principle. Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. This is also known as design by contract.

I – Interface segregationpPrinciple. Many client specific interfaces are better than one general purpose interface.

D – Dependency inversion principle. One should depend on abstractions. Do not depend upon their concretions. This is where you decouple comes into play.

A very good book that covers the SOLID principles is Clean Code, by Robert C. Martin. I recommend that every software developer should read this book.

Clean Code by Robert C. Martin

As I stated above, if you rigorously follow these principles and ingrain them into the way you right code, you will find that you genuinely do not need to resort to mocking libraries to mock out dependencies as your code will naturally start to become decoupled. I would even go as far as saying that if you feel the need to use a mocking library then that should be a code smell indicating there is a design problem.

Mocking libraries do have their place though. As with most tools, they are a valuable tool in your tool box for specific purposes. If you inherit a large, badly written legacy system, otherwise known as a Big Ball of Mud, the first thing you want to do before changing the code is get some tests around what is there already. These tests are called characteristics tests. This is where you need to test what the current functionality does. This functionality may be wrong or buggy, but you want to get a test suite in place so that you know whether you have broken/changed anything as part of your refactoring. Normally because of excessive class coupling you will need to use a mocking library to write these tests. In this scenario I think mocking libraries are perfect and this is when I would use them, but as you start refactoring your code and trying to introduce some of the solid principles you need to plan for how you are going to remove these mocks and write simpler tests.

There is a great book on all of this called Brownfield Application Development in .NET by Donald Belcham that covers this exact subject.

Brownfield Application Development in .NET by Donald Belcham

That concludes my views on mocking frameworks. I am sure there are developers reading this thinking “Hey, I use mocks and can write decent tests that work at the correct layers”, and I am sure you can. Part of my view on this subject comes from leading mixed ability teams of developers where I have seen these libraries abused so many times before. I now encourage my team to work with the SOLID principles and write tests the good old fashioned way.

I know this is a subject that developers are passionate about. I am not claiming this way is the only way, but it is the way that works for me and my team. If you have any views on this, then I invite you to share them in the comments for this post.

]]> http://adamprescott.net/2013/03/06/definition-of-a-good-unit-test/ Wed, 06 Mar 2013 14:00:08 +0000 Adam Prescott http://adamprescott.net/2013/03/06/definition-of-a-good-unit-test/ I’m constantly encouraging developers around me to embrace test-driven development and automated unit testing. However, there’s one very important thing I’ve neglected to include in my evangelizing: a definition for what constitutes a good unit test.

A big problem that I think a lot of developers run into is that they’re writing tests but aren’t realizing any value from them. Development takes longer because they have to write tests, and when requirements change it takes longer because they have to refactor tests. Maintenance and warranty work is slower, too, because of the additional upkeep from failing tests created with every little change.

These problems mostly exist because of bad unit tests that are written due to insufficient knowledge of what makes a good test. Here’s a list of properties for a good unit test, taken from The Art of Unit Testing:

• Able to be fully automated
• Has full control over all the pieces running (Use mocks or stubs to achieve this isolation when needed)
• Can be run in any order  if part of many other tests
• Runs in memory (no DB or File access, for example)
• Consistently returns the same result (You always run the same test, so no random numbers, for example. save those for integration or range tests)
• Runs fast
• Tests a single logical concept in the system
• Readable
• Maintainable
• Trustworthy (when you see its result, you don’t need to debug the code just to be sure)

This is a great list that you can use to gut-check your unit tests. If a test meets all of these criteria, you’re probably in good shape. If you’re violating some of these, refactoring is probably required in your test or in your design, particularly in the cases of Has full control over all the pieces running, Runs in memory, and Tests a single logical concept in the system.

When I see developers struggling with unit tests and test-driven development, it’s usually due to test “backfilling” on a poorly-designed or too-complex method. They don’t see value because, in their minds, the work is already done and they’re having to do additional work just to get it unit tested. These methods and objects are violating the single responsibility principle and sometimes have many different code paths and dependencies. That complexity makes writing tests hard because you have to do so much work upfront in terms of mocking and state preparation, and it’s really difficult to cover each and every code path. It also makes for fragile tests because testing specific parts of a method rely on a test’s ability so successfully navigate its way through the logic in the complex method; if an earlier part of the method changes, you now have to refactor unrelated tests to re-route them back to the code they’re testing. (Tip: Avoid problems like this by writing tests first!)

Whether you’re just getting with unit tests or a grizzled veteran, you can benefit from using this list of criteria as a quality measuring stick for the tests you write. High-quality tests that verify implemented features will result in a stable application. Designs will become better and more maintainable because you’ll be able to modify specific functionality without affecting the surround system the same way that you’re able to test it. You won’t have to worry about other developers breaking functionality you’ve added, and you won’t have to worry about breaking functionality they’ve added. You’ll be able to make a modification that affects the entire system with a high-level of confidence. I’d venture to say that virtually every aspect of software development is better when you’ve got good tests.

I was less than half way home, enjoying the freedom of my new ride, when a passenger in a car a couple of lanes over caught my attention. She wanted to know where Pier 39 was. Despite not being an SF resident, I have been here enough that it was an easy question to answer. And that’s when duck typing came to mind.

Just as we say when it walks like a duck and quacks like a duck, it must be a duck, it seems as if when she commutes like a SFer and she must be a SFer. In this case, not exactly true, but it got the mission accomplished. Perhaps the unit test gave a false positive, but maybe I should also stop with these crazy analogies.

And, given that, I just want to say that at this point I wish I would have bought this bike sooner. Not only will my commute time likely go done, I’ll be getting some reasonable exercise at the same time. And I won’t be at all upset that I am trading off a bit of upper arm strength building while bracing for sudden starts and stops on an almost always packed as sardines bus for some good old fashioned aerobic work. This is even more true since I haven’t been able to run lately due to my foot being overly sensitive recently.

Sadly it is supposed to be raining in the morning, hopefully it will have tapered off by commute time, fingers crossed.

Wendy

So headless browser was my answer to the situation. Go grab HtmlUnit from here http://sourceforge.net/projects/htmlunit/

Once you add the reference to the downloaded jars it becomes a straight forward process. Basically this snippet below walks through the process of clicking through the pages and retrieveing the auth token.

This code assumes that you are not already logged into your oauth account, in which case, some conditional handling will be required. I will try to update the snippet soon. Meanwhile add the following lines to your authentication code to get the auth token automagically !!!

GoogleAuthorizationCodeFlow flow = new GoogleAuthorizationCodeFlow.Builder(httpTransport, jsonFactory, CLIENT_ID, CLIENT_SECRET, Arrays.asList(DriveScopes.DRIVE)).setAccessType(“online”).setApprovalPrompt(“auto”).build();
String url = flow.newAuthorizationUrl().setRedirectUri(REDIRECT_URI).build();

HtmlPage page = webClient.getPage(url);
HtmlSubmitInput signInButton = (HtmlSubmitInput)page.getElementByName(“signIn”);
HtmlTextInput userNameField = (HtmlTextInput)page.getElementByName(“Email”);
HtmlPasswordInput passwordField = (HtmlPasswordInput)page.getElementByName(“Passwd”);

userNameField.setValueAttribute(“YOUR_USER_NAME”);
passwordField.setValueAttribute(“YOUR_PASSWORD”);

HtmlPage allowAccessPage = signInButton.click();
HtmlButton allowAccessButton = (HtmlButton)allowAccessPage.getElementById(“submit_approve_access”);
HtmlPage tokenPage = allowAccessButton.click();

HtmlTextInput tokenElement = (HtmlTextInput)tokenPage.getElementById(“code”);
String code = tokenElement.getText();

webClient.closeAllWindows();
GoogleTokenResponse response = flow.newTokenRequest(code).setRedirectUri(REDIRECT_URI).execute();
credential = new GoogleCredential().setFromTokenResponse(response);

And you are all set.