Derik Whittaker : TDD

Running Typescript tests via Jasmine and Chutzpah on Teamcity

Derik Whittaker — Wed, 26 Dec 2012 00:54:27 GMT

In my prior post I talked about how I setup my environment for testing my Typescript source via Jasmine and Chutzpah. That was just the beginning. Now that I had the ability to create unit tests I needed the ability to run them on our CI server, which happens to be Teamcity). I did a bunch of looking around and could not find anything that seemed to work for me, but I did notice that Chutzpah had the ability to run via the command line… GOLD.

Armed w/ the knowledge that I can run my tests from the command line I gave it a whirl. After looking at the docs it appeared I could run get the results I wanted w/ the following.

chutzpah.console.exe /path “c:\path_to_my_typescript_folder_here /teamcity

However, when I ran the above command I got the following output

If you look at the above you will see 33 total test, 22 failures. This is odd because I only have 11 tests. Turns out the command line tool is running my .js files (ones generated via Typescript) and my .ts files. I only wanted to run my .ts files. I figured there had to be a command line switch, but there was not. This sucked because inside of Visual Studio i can set it to ONLY run typescript files as seen below.

I figured I would take a peek at the source to see if I could add support for TestingMode via the command line, turns out I could (side note, I created a fork here and have submitted a pull request for my changes so i hope they are consumed soon)

Now I can run the command w/ the new “/TestMode Typescript” option as below

chutzpah.console.exe /path “c:\path_to_my_typescript_folder_here /testMode TypeScript /teamcity

When I run the above command I get below

With my commits you will see the /testmode option via the help as below

Once I had a working version of Chutzpah which can output my test results all I needed to do was add it to my build script (we use pSake) and bam, I now have Typescript/Javascript tests showing up in my Teamcity builds as seen below

or as shown from from our Teamcity logs

Hope this helps

Till Next Time,

P.S. If you need a copy of my .exe before my changes are added to the master branch let me know.

Setting up Unit Testing w/ Jasmine, Chutzpah and Typescript

Derik Whittaker — Sun, 23 Dec 2012 12:49:46 GMT

Recently I got back into writing html/javascript code as part of my day job and boy-o-boy have things changed since the last time i did any of this. One thing that has not changed for me however was my belief in unit testing, so it was very painful for me to be writing hundreds of lines of javascript (ok really TypeScript) code with NO tests supporting them. At first I was able to live with this feeling because I was too busy trying to relearn how to do javascript development. However, I have not reached a comfort level where the lack of tests is killing me again.

No of course in client/server land of .Net development getting started testing is dead simple, however in the Javascript/html world things are still in the toddler stage, IMO, and there are many, many options to testing and I had no idea which is the best. After doing some searching and asking on twitter I settled on Jasmine as my test runner.

Now that I picked Jasmine, how did I get started? Here is what I did (this post is a merging of many, many posts I looked at to get me pointed in the right direction)

Step 1: Create a new test project

Open up Visual Studio 2012 and create a basic MVC 4 application (empty)

Step 2: Get Jasmine

Install the Jasmine NuGet Package

Step 3: Run your application in order to validate that jasmine is running correctly

Yup, we are good

Step 4: Get Chutzpah

I wanted a way to run my tests inside of Visual Studio and this plugin seemed to do the trick. I opted to install the test adapter which can be found here

Step 5: Validate that Chutzpah adapter was setup correctly

As you can see from above, it is setup correctly.

Now I wanted to be able to author my tests in Typescript and have them run as well.

Step 6: Download the Jasmine typescript definition file. I put this inside my scripts folder as seen below

Step 7: Create my Test Spec

The trick to getting this to work of course is that I need to include the jasmine-1.2.d.ts definition file inside my .ts file as below

I also need to reference my class under test file inside my .ts file as below

Once I did both of these I could write my first test as below

Bam, now I have a jasmine test written via Typescript and runnable via the Chutzpah test running. Of course I am sure there are other ways to get this to work, this is just what worked for me.

Till next time,

Unit Testing Silverlight from MSTest–Forcing VS to use the right Silverlight Assemblies

Derik Whittaker — Fri, 26 Aug 2011 13:13:14 GMT

Ok, silverlight and unit testing just plan sucks, I firmly believe that the devs for silverlight did NOT care about testability, but that is off topic. When doing any type of unit testing (and not with the built in silverlight testing framework which actually runs the app, talking code level testing) you will quickly run into an issue of version mis-match.

The issue with the version mis-match is that VS wants to push the 4.0 version of your assemblies, even when you add direct reference to the 2.0.5 version (silverlight version). When this happens your tests will fail with an error telling you that your assemblies are not the right version. And if you are like me you will try over and over to ‘force’ vs to reference the right version and it will fail. The good news is that there IS a way around this, but it is a bit of a hack

How to get around this issue (at least one way)

Move copies of your desired Silverlight .dlls into a local library folder. I have the following in my folder
1. System.ComponentModel.DataAnnotations.dll
2. System.Net.dll
3. System.Runtime.Serialization.dll
4. System.ServiceModel.dll
5. System.ServiceModel.DomainServices.Client.dll
6. System.Windows.dll
7. System.Xml.dll
Open up your unit tests .proj file in notepad or any text editor

Find the <Reference> entry to the correct silverlight dll you want and create a hint path which points to your LOCAL dll
See this example:
<Reference Include="System.ServiceModel">
<HintPath>..\..\..\Libraries\Silverlight Test dlls\2.0.5 DLLs\System.ServiceModel.dll</HintPath>
</Reference>

Save the .proj file
Open it back up in VS (or reload)
Verify the correct version is not being used by viewing the properties of the dll in VS
Get back to testing

As you can see this is fixable, but it is also a bit of a hack/work around. However this little bit of pain is worth the gains of adding tests to your code. Now if only silverlight as a framework was more testable

Till next time,

Testing that EventHandlers were wired up correctly with NUnit and Rhino Mocks

Derik Whittaker — Tue, 24 Aug 2010 11:04:04 GMT

Today I was trying to wrap some code in some tests (I got lazy and did not create the tests first… shot me). What I was trying to ensure was that my event handlers I passed into a method were actually being wired up for usage. Now I searched around the net for a while to see if there was a elegant solution to this problem but I could not find one. Below is the solution I came up with. Mind you this may not be a great solution, hell it may just down right suck but it works for me.

First things first, her is the method i was trying to provide coverage for

public void GetAppointments( DateTime? from, DateTime? to, 
    EventHandler localRequestStarted,
    EventHandler remoteRequestStarted,
    EventHandler> requestFinsished )
{
    var currentUser = _sessionManager.GetValue();
    var dataRequest = new AppointmentDataRequest( new AppointmentParameterContext( currentUser.ResourceIds, from.Value, to.Value ) );

    dataRequest.LocalRequestStarted += localRequestStarted;
    dataRequest.RemoteRequestStarted += remoteRequestStarted;
    dataRequest.RequestFinished += requestFinsished;

    _dataManager.Fetch( dataRequest );
}

As you can see there are 3 lines in the above code where the passed in EventHandlers are being attached. I wanted to ensure this. But what you may also see is that I have no direct access to the dataRequest object which is being created in this method. That is where our handy rhino mocks library comes in. With Rhino Mocks I am able to get the pointer to the various values which are passed into methods. Check out the test below and you will see how this is done.

My unit test

[Test]
public void GetAppointments_WhenCalled_EnsureWillWireupEventsCorrectly()
{
    var dataManager = MockRepository.GenerateMock<IDataManager>();
    var sessionManager = MockRepository.GenerateMock<ISessionManager>();

    var currentUser = new CurrentUser();
    sessionManager.Stub( x => x.GetValue<CurrentUser>() ).Return( currentUser );

    var provider = new AppointmentProvider( dataManager, null, sessionManager, null );
    bool localWired = false, remoteWired = false, requestFinishedWired = false;

    EventHandler<LocalRequestStartedEventArgs> localRequest = ( s, arg ) => { localWired = true; };
    EventHandler<RemoteRequestStartedEventArgs> remoteRequest = ( s, arg ) => { remoteWired = true; };
    EventHandler<RequestFinishedEventArgs<object>> requestFinished = ( s, arg ) => { requestFinishedWired = true; };

    provider.GetAppointments( DateTime.Now, DateTime.Now, localRequest, remoteRequest, requestFinished );

    IList<object[]> argumentsForCallsMadeOn = dataManager.GetArgumentsForCallsMadeOn( x => x.Fetch( Arg<DataRequest>.Is.Anything ) );

    var dataRequest = (AppointmentDataRequest)argumentsForCallsMadeOn[ 0 ][ 0 ];

    dataRequest.RaiseLocalRequestStarted();
    dataRequest.RaiseRemoteRequestStarted();
    dataRequest.RaiseDataRequestFinished( DataRequestType.UserLogin, DataRequestResult.Unknown, null, null );

    Assert.That( localWired, Is.True );
    Assert.That( remoteWired, Is.True );
    Assert.That( requestFinishedWired, Is.True );

}

As you can see this test has a lot going on, but let me explain some of this for you.

1) First thing we need to do is create a few local variables which will hold the state of the event firing

2) Next we want to create local copies of our event delegates in order to push them into our method

3) Next is time for the Rhino Mock magic. Notice how I am calling the GetargumentsForCallsMadeOn() method. This is a method in Rhino Mocks which allows me to reach into the call stack and pull out the values which were pushed into a method when it was called. I then cast the argument i want to its native type.

4) In order to ensure the events were wired up I need to call the various ‘raise’ methods in order to trigger them. Doing this should cause my local state holders for the events to be changed and this is what we actually want to ensure

5) Ensure the event state variables were set to true.

There you have it, a simple (well kinda) way to ensure that your events have been registered correctly in your code.

Till next time,

Testing only the code of value

Derik Whittaker — Wed, 07 Oct 2009 11:48:25 GMT

I am 99% sure I have had a post like this in the past, but my google-foo was weak today and I could not find it. Do not let anyone blow smoke up your back side, testing is expensive, testing takes time but most importantly testing can help improve the quality of your code.

If you are going to spend the time and money to create automated, rerun-able unit tests make sure you spend your time/money wisely. Make sure you test the code that matters, test the code which is complicated (keep in mind a LOC count does NOT equal complexity).

Today when scanning some code in another part of our project I came across this tests:

public void AdminSetIDTest()
{
	var target = new CreateTaskActivity();
	int expected = 50;
	int actual;
	target.AdminSetID = expected;
	actual = target.AdminSetID;
	Assert.AreEqual(expected, actual);
}

When I looked at this tests 2 bells immediately went off in my mind

The name of this tests SUCKS BALLS and does not clearly convey the intent of the test
This is testing that a property getter works (no, there is NO logic behind the getter/setter)

If you disregard #1 from above for now (but remember clear/concise names do matter) and focus on #2 this tests adds no value to the test suite. All this test is doing is ensuring that the .Net framework does its job. This test is a total waste of time and energy and can actually cost you more time/money in the long run because you may have to change the useless test over time as you refactor.

The key take away from this is simple. You always have limited time and money when trying to get a product out the door. Unit testing IMO can always help you to create a better product, but make sure you use your time and money in a way in which will allow you to maximize your ROI.

Till next time,

Your unit test may smell if…….!

Derik Whittaker — Wed, 09 Sep 2009 17:28:30 GMT

If you find yourself using reflection in your unit test to push 'stub’ data into it your test just may smell. Now there are times (especially when dealing with legacy code) that you need use reflection to crack open a class to push/pull values but I would strongly suggest you consider the solutions I am going to suggest.

Utilizing the wrap method (see Working with Legacy Code) to accomplish your goal.

Lets assume you have the following class which you want to test:

  public class SomeClass 
  {
    private DateTime _lastVerified;
    private DateTime _lastActivated;
   }

Now one way to push data into these fields would be to do the following:

    [Test]
    public void IsTimeToActivateTrueLastActivatedTheDayBeforeCurrentTimeAfterActivationTimeTest()
    {
      SomeClass accessor = new SomeClass 

      Type type = SomeClass 

      FieldInfo field2 = type.GetField("_lastActivated", BindingFlags.Instance | BindingFlags.NonPublic);
      field2.SetValue(accessor, new DateTime(2008, 2, 29, 10, 5, 0));

      FieldInfo field3 = type.GetField("_lastVerified", BindingFlags.Instance | BindingFlags.NonPublic);
      field3.SetValue(accessor, new DateTime(2008, 3, 1, 10, 0, 0));
    
      DateTime currentDateTime = new DateTime(2008, 3, 1, 10, 10, 0);

      MethodInfo method = type.GetMethod("SomeMethod", BindingFlags.Instance | BindingFlags.NonPublic);
      object result = method.Invoke(accessor, new object[1] { currentDateTime });

      bool isTime = (bool)result;

      Assert.AreEqual(true, isTime);
      Assert.AreEqual(currentDateTime, field3.GetValue(accessor));
    }

Now this works, but if you do this over and over again you will kill yourself with reflection code.

Option 1) Create a subclass of your class and hide the reflection inside your subclass

public class MySubclassOfSomeClass : SomeClass
  {
    public void SetLastActivatedTime( DateTime value )
    {
    	// set the value via reflection here
    {
	
    public void SetLastVerifiedTime( DateTime value )
    {
    	// set the value via reflection here
    {
   }

The code above will still use reflection to set the value, but it will hide the usage of reflection from your unit test and will present a less noisy test to future developers

Option 2) Change the scope of the fields and subclass and extend

  public class SomeClass 
  {
    protected DateTime _lastVerified;
    protected DateTime _lastActivated;
   }

public class MySubclassOfSomeClass : SomeClass
  {
    public void SetLastActivatedTime( DateTime value )
    {
    	_lastActivated = value;
    {
	
    public void SetLastVerifiedTime( DateTime value )
    {
    	_lastVerified = value;
    {

If you change the scope of the fields to protected you could subclass the original class and do the same as option 1, but because you have access to the fields via inheritance there is no need to use reflection.

So, remember that tests are code to and if you feel pain writing test you may be doing it wrong.

Till next time,

You know you buy into Testing and Testabilty when you wrap a singleton simply to create an abstraction…

Derik Whittaker — Fri, 15 May 2009 22:27:58 GMT

I am a little bored so I thought I would write a nice fluent interface around the Performance Counter crap that is part of .net. I know, I know the world does not really need another Fluent Interface around something, but I am bored and this is keeping be busy while waiting for my flight.

Anyway, about 30 min into the coding session (going a bit slow as I am trying to use CodeRush/Refactor Pro in place of ReSharper) I needed to use the PerformanceCounterCategory class. The problem is this. Since this is a singleton isolating this during my tests is too painful, and because it is a singleton I cannot create an inheritance hierarchy to allow me to isolate it better. So, what did I do?

I created a wrapper around the singleton. By having this wrapper (and accompanying interface) I will be able to better isolate my tests and not actually create a shit load of categories and counters all the time.

Wrap Strategy Refactoring === FOR THE WIN

Singletons == FOR THE LOSS

Till next time,

Teaching someone to test using an Isolation Framework

Derik Whittaker — Tue, 30 Dec 2008 17:21:12 GMT

Part of my job at work is to teach and mentor other developers on our team. Right now I am in the process of teaching two of our developers how to create unit tests (notice I did NOT say integration tests because most anyone can do those). We are also learning how to create our tests by utilizing an Isolation Framework (aka mocking framework).

I am really excited for this opportunity because I firmly believe that you create better software when you do it by creating tests to prove your code works. I am also excited because both of the developer buy into the idea of testing and are extremely eager to learn how to to better test their code.

Because we had a few days of downtime because of the Christmas holiday before our 1st sprint on our project we thought it would be a good time to do some pairing (guess it would be better called tri-pairing). Our plan of attack was to start to flush out some of the features in our system but do it in a total TDD manor. We were also going to be utilizing the Rhino Mock Isolation framework in our tests.

So over the next 2 days we spent about 12 hours or so working building out our code. Over this time we actually were able to create an complete end to end 'version' (I say version because we did not fill in all the functionality of the code but were able to get all the major pieces stubbed out) which allowed us to flush out many, many more business requirement and build a simple, yet flexible code base.

I hope both of my co-workers learned a ton from this exercise, I know I did. This was the first time where I had actually spent any significant amount of time teaching someone who was new to testing how to do so. Sure I had spent an hour here or an hour there, but nothing like this.

What I really wanted to share with everyone is what I learned form this experience.

Slowdown, slowdown, slowdown
The first thing you should do when teaching something how to do anything is SLOWDOWN. You have to remember that if you are talking/teaching to someone who is new to this they have to not only try to process the information so they can understand it, they also have to try to remember it.

Make NO assumptions, teach as if they know nothing
This one was the most important thing I learned. You cannot make assumptions on anything. Anytime you say anything make sure you fully explain it. If you use an acronym EXPLAIN IT. Any time you mention a buzz word EXPLAIN IT. Plan and simple EXPLAIN EVERYTHING

Have them drive
During the teaching part it is critical that you have then code, have them tell you what to do. It is ok for you to 'lead' them in the right direction, but you must not always drive. This will really help to drive home the concepts.

Provide examples both with and without the Isolation framework
In our case because I was trying to teach them testing using an Isolation framework it really helped when I would create a test (aka integration) with no mocks and then re-create it with mocks. Doing this really helped to explain to them how using the Isolation framework removed dependencies.

Don't let them skate by
Don't let them simply nod their head as if they understand. Make sure you keep asking them if there is anything you can clear up or explain better. At first they are going to simply say no, they are good. But as you keep asking and start having them drive they WILL start to ask more questions, I promise.

Turn off any coding tools such as ReSharper (or the likes) and do NOT use shortcuts
This may have been the biggest issue for us at first. I am pretty good with ReSharper (if I can toot my own horn here) and I was coding with it as I would do if I were by myself. On more than one occasion the would look at me cross-eyed and ask 'what the hell just happened'. Finally I simply stopped using it for the first day. On the second day I went back to using R#, but I turned on Keyboard Jedi so they could see what was going on. Even though I turned on Keyboard Jedi, I tried my best to make sure to explain what just happened when used R#.

Anyway, I have rambled on long enough and I think I have pretty much gotten my thoughts out there. I really enjoyed working with these guys and I am looking forward to doing so again when we get back from break.

Hope this helps,

Till next time,

Testing is hard but debugging just sucks A$$

Derik Whittaker — Fri, 14 Nov 2008 23:58:05 GMT

In my last post (here) I was giving a wrap up of the Mocking session I recently did at TriNug. In that post I gave some of the reasons (sorry, I meant excuses) people gave for not doing any type of automated testing during their dally development ritual (notice I am staying away from TDD at this point). I thought that those topics would be better suited to be broken out into their own post.

At the users group I asked the question to the group 'who creates automated tests as part of their daily development cycle?'. After I asked this question I followed it up with, and if you don't WHY, WHY, WHY, WHY...... Below are some of the answers I received (btw, not the first time I have heard these reasons).

Reason #1 - It is too hard to get started:

Point: This statement is nothing new, I hear this all the time. To be honest I agree with them, testing is hard. It takes time and effort to learn how to do it.

Counter Point: But if you think learning to write tests and learning how to create testable code is hard, then what do you do when you need to learn a new product? I can break it down like this. Testing == Coding and Coding == REAL FREAKING HARD. Stop using 'testing is hard' as a crutch and just give it a shot.

Reason #2 - My client/company is not paying me to write tests:

Point: This one always make me laugh. Since testing does take time (not going to sugar coat this at all), and can slow down your pace of development, many people feel that they are not being paid to create tests.

Counter Point: This one is real simple, ask your self these two questions.

Am I being paid to produce quality or crap?
Am I being paid to debug?

I am going to assume that both of those answers are NO, and if they are not then I would suggest you stop reading this post as it does not get any better from here.

Now that we are on the same page and we understand you are being paid to produce quality code why would you not want to do everything you can to bake that quality into your code up front? This can happen with tests. Take the time, take the challenge and create some tests. Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint (and if you do get fired because of it just look at it this way, you have a new and marketable skill to help you find your new job).

Reason #3 - I do not have time

Point: Testing takes time, and when time is short people throw every 'non-critical' functions out the window. And sadly people think that quality is a non-critical function. To prove this point just take a look at 90% of the applications out there... they suck ASS

Counter Point: Just ask yourself this question. Would I rather spend what little time I have creating tests to help ensure I have quality or would I rather spend time later stepping through code via the debugger looking for the bug I could have caught/fixed earlier? If you would rather spend time in the debugger, then more power to you.

NOTE: Do NOT take the above statement as me saying that testers NEVER debug, they do but just a TON less than others.

Reason #4 - My code will not allow me to tests

Point: This is one may be the only excuse that has some merit. Poor code is hard to test.

Counter Point: Simply because you do not need to retrofit your entire code base at one time. If you have 'bad' code that is easy to test that is fine. Start testing with NEW code. Hopefully you will not be creating bad code once you understand your current code is not the best. You will also come to understand that when you start testing your code will start to get a little cleaner. Finally, if you really want to start to test your legacy code, go out and pick up 'Working Effectively w/ Legacy Code' by Michael Feathers

As you can tell from my tone, I do not buy into any of these reasons, sorry excuses. I wish that when I ask people this question and they gave me a response they would simply state the truth. And the truth is people do not test for the following 2 reasons

Reason #1 - They do not believe that creating tests will improve their code
If this is what you really think, that is fine. You are allowed to have your beliefs and I am allowed to have mine. As long as we understand each other we can get along just fine.

Reason #2 - They are lazy
Not sure I need to explain this one.

Let the flames begin :)

Till next time,

Talking Mocks at TriNug, what a great time, what a great group

Derik Whittaker — Thu, 13 Nov 2008 12:36:01 GMT

Last night I had the opportunity to do my 'Taking your tests to the next level with Mocks' session to the TriNug user group. I would first like to say thanks to Doug Wilson and his entire group. They had a great turn out (45ish people) and they asked a ton of great questions.

To kick off the session I ask the same question I ask everything I give this session 'Who in here writes tests as part of their development routine?'. The response I got did not surprise me, about 30% said they did. I then asked those 30%, who using a mocking framework? Again the response did not surprise me, only about 50%.

Of course with only 30% even saying they test, I had to ask why, why and why. The responses I got I have heard before and thought I would share them

It is too hard to get started
I have heard this one before, and I am not going to lie to you, writing tests is hard, it takes effort and time to learn how to do it. But just ask yourself this. When learning anything new is it easy? Are you able to just pickup a new tool/technology and 'know it' or do you have to learn it? My guess you have to learn it, testing/mocking is no different.
My client/company is not paying me to write tests
Sorry, but this is one statement have to call BS on. I immediately asked, is your company paying you to write shitty quality? Or are they paying you to produce quality code? If they are paying you to write shitty code, STOP reading now as I am done talking to you (ok, may be not, but really??? shitty code is what they want???). If they are paying you to create quality code how can you insure it without tests? My guess is that you have tests, but they just happen to be of the manual, error prone nature.
I do not have time
Again, another one I call BS on. I followed this up with 'let me guess, you have time to debug/bug hunt at the end right?'. The key to testing is that it does take time (wow, that is honest) but it is either a pay me now, or pay me later scenario. Either you take the time now to embed quality or you take the time later to duck-tap quality. Your choice?

With this information in hand, I really attempted to drive home the values of both testing as well as using a mocking framework to remove dependencies. I think towards the end of the night I had converted some people to 'believers' and hopefully they will either give testing a solid go (assuming they are not testing right now) or give using a mocking framework a go.

You can get any of my session information from Google code from this location http://code.google.com/p/graudo/.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Using the RhinoAutoMocker that is part of StructureMap 2.5

Derik Whittaker — Sun, 05 Oct 2008 18:58:25 GMT

One of the new features that is part of the next release of StructureMap 2.5 is a AutoMocking Container.

What is an AutoMocking Container, well per Jacob over at Eleutian an AutoMocker is

AutoMockingContainer is simply a IoCContainer with a custom facility and dependency resolver that supplies a Mock (RhinoMock) for any interface that is resolved.

My definition is a little more straight forward and uses simpler word (remember I am a simpleton :))

An AutoMocking container is simply a tool that will inject mock dependencies into your object for you.

What I want to do today is show how an AutoMocking Container can reduce the amount of code/noise from your tests. I am going to first show a tests that simply uses RhinoMocks then that same test that uses the RhinoAutoMocker

Test with only RhinoMocks

[Test]
public void NoAutoMocker()
{
	var mockProvider = MockRepository.GenerateMock<IPersistingRulesProvider>();
        var mockRepository = MockRepository.GenerateMock<ISynchronizationRepository>();
        var mockPersistanceProvider = MockRepository.GenerateMock<IPersistanceProvider>();
        var mockLogger = MockRepository.GenerateMock<ILogger>();

	// Expectations
        mockProvider.Expect(x => x.ExecuteRules(null)).IgnoreArguments().Throw(new Exception("Do not care what this is"));
        mockRepository.Expect(x => x.StartTransaction()).Repeat.Once();
        mockRepository.Expect(x => x.RollbackTransaction()).Repeat.Once();
        mockRepository.Expect( x => x.CommitTransaction() ).Repeat.Never();

	var persitingPipeline = new PersistingPipeline(mockProvider, mockPersistanceProvider, mockRepository, mockLogger);
        var result = persitingPipeline.PersistChanges(new DataSet(), 0, 0, 0);

	Assert.That( result, Is.Not.Empty );

	mockRepository.VerifyAllExpectations();
}

This code above has a bit of noise. Because my object has a dependency on 4 other objects i need to create mocks for each of these. This creates more work and just adds to the test noise.

Test with the RhinoAutoMocker

[Test]
public void WithAutoMocker()
{
	var mockPipeline = new RhinoAutoMocker<PersistingPipeline>();

	mockPipeline.Get<IPersistingRulesProvider>().Expect( x => x.ExecuteRules( null ) ).IgnoreArguments().Throw( new Exception( "Do not care what this is" ) );
	mockPipeline.Get<ISynchronizationRepository>().Expect(x => x.StartTransaction()).Repeat.Once();
        mockPipeline.Get<ISynchronizationRepository>().Expect(x => x.RollbackTransaction()).Repeat.Once();
        mockPipeline.Get<ISynchronizationRepository>().Expect(x => x.CommitTransaction()).Repeat.Never();

	var result = mockPipeline.ClassUnderTest.PersistChanges( new DataSet(), 0, 0, 0 );

	Assert.That( result, Is.Not.Empty );

}

The code above does not require me to create mocks for each of my dependencies, the AutoMocker will do that for me.

Also notice that when I need to set an expectation for a dependencies I can access it via the .Get<>() method.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Clean build server with MSTest == FAIL

Derik Whittaker — Thu, 25 Sep 2008 10:10:32 GMT

It is no secret that I am not a fan of MSTest (read here for more rants on MSTests). Today's rant is about how MSTest does not allow you to have a clean build server.

Yea I know what you are thinking, here comes another long winded rant on MSTest. Well this should not be too long winded, and hey, it is my blog and I can rant if I want to :).

This week I was trying to setup our build server and I need it to run MSTest tests. I know that MSTest does not run like NUnit, but thought for sure there was a way I could get my tests to run without having to install the full blown version of Visual Studio. After a bit of searching and asking others I came to final conclusion that in fact you cannot get MSTest to run without Visual Studio.

This is an issue to me because when I setup my build server I like to keep it clean. I do NOT want to install any 3rd party software. The way I see it is like this. If we are not going to install the software package on the end users computer, why should I need to install them on our build server, and the last time I checked we do not install Visual Studio on our end users computer.

This is another issue to me because MSTest is the ONLY test framework (for .Net) that I know of that does not run with a single DLL placed into the bin (or any other output directory). I just have to ask the genius' over in Redmond what the hell were they smoking when they decided to build MSTest. It is pretty clear they had no prior knowledge of how to use the other tools such as NUnit, MBUnit or xUnit (I know, xUnit was not out yet). I know this because of all the various testing frameworks MSTest is the one that does everything different. You could argue they were on the cutting edge and were innovating, but I call BS on that.

Anyway, I feel better now telling the world another reason why I am not a fan of MSTest. Sadly I am stuck using it for now and at least in the short term as we have hundred of tests already written in MSTest. But rest assured that I am on a crusade to get our team to switch from MSTest to NUnit (or any other logical framework).

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Testing your IoC Bindings

Derik Whittaker — Wed, 10 Sep 2008 11:53:55 GMT

One thing I like to do when I am using a IoC (Inversion of Control) container is to create simple test that ensure that my objects have been wired up correctly and can be created via the IoC container.

I know this may seem like overkill, but I feel that by having my IoC bindings covered by tests I am covering all my bases.

So, what does testing my bindings do for me

Allows me to know if my object is configured correctly
By having these tests I will know immediately if I have somehow broken my IoC bindings glue (yes, glue is the technical term in this case).

It is not hard to phantom that when making changes to your IoC bindings logic (either via config files or via inline code) you can mistakenly break something. Having these tests provides me immediate feedback if this were to happen.
Allows me to know if my objects dependencies are configured correctly
Setting up the wiring for your main object is only half the battle. When using an IoC container many time you are going to have that container do some sort of Constructor Injection of your dependencies.

By having tests that simply create my object with IoC I will find out immediately if one of my dependency objects is not wired up. This scenario is pretty common and having this test can save you some headaches.

Here is the test code I use for my IoC bindings tests:

[Test]
public void CanCreateViaDI()
{
var iocObject = ObjectFactory.GetInstance< YourObjectHere >();
Assert.That( iocObject, Is.Not.Null );

}

Hope this helps someone.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Is it evil to use reflection when testing?

Derik Whittaker — Tue, 29 Jul 2008 11:55:29 GMT

I have a scenario where I have a private method that needs to be tested and the only way I can get to that method is by calling another public method and exercising all of its logic.

This private method has a few different pathways and I would like to create tests for each of them. I could do this by creating tests for the public method and just ensure that each of the tests exercise the various pathways of the private, but that just seems like too much work and effort.

So, my question to you is this. Is it evil to use reflection to test a private method?

BTW, I know I could make the method internal and use the [InternalsVisibleTo] trick, but I do not want to make this method internal?

Thoughts, opinions, feedback,

Till next time,

[----- Remember to check out DimeCasts.Net -----]

RhinoMocks new Arrange, Act, Assert does not seem to work under MSTest....odd

Derik Whittaker — Wed, 23 Jul 2008 15:38:39 GMT

-- UPDATE See text in red below --

Ok, I am in NO way trying to say that this is either Rhino's issue or MSTest. I am simply blogging this with the intent that someone can shed some insight as to what may be going on. Although, since I know that the AAA logic of Rhino works with the EXACT same code under NUnit i have to believe it has something to do with the MSTest works.

So here is my propblem:

I have a test where i want to mock out and set an expectation on a repository. When I tried the code via the AAA syntax my expectation would only return a null. When I changed to use Record/Playback everything worked well. Odd.

Here is the syntax for AAA (non-working)

var mockRepository = new MockRepository();
var mockStatusCheckRepository = mockRepository.DynamicMock();

mockStatusCheckRepository.Expect( x => x.GetCustomerAuditInformation( "", "" ) ).IgnoreArguments().Return( new CustomerAuditInformation { NeedsInitialDataCreated = true } ).Repeat.Once();
var information = mockStatusCheckRepository.GetCustomerAuditInformation( "", "" );
// Returns null

I was able to get this working by NOT using the instance of MockRepoistory, instead using the Static Methods. Belows Code works

var mockStatusCheckRepository = MockRepository.GenerateMock();

mockStatusCheckRepository.Expect( x => x.GetCustomerAuditInformation( "", "" ) ).IgnoreArguments().Return( new CustomerAuditInformation { NeedsInitialDataCreated = true } ).Repeat.Once();

var information = mockStatusCheckRepository.GetCustomerAuditInformation( "", "" )

So, this may just be a case of me not fully understanding the new AAA syntax and how to use it, but I know that using the instance stuff works under NUnit... odd

Here is the syntax for the Record/Playback (working) - Can use the AAA syntax above as well

var mockRepository = new MockRepository();
var mockStatusCheckRepository = mockRepository.DynamicMock();

using ( mockRepository.Record() )
{
    mockStatusCheckRepository.Expect( x => x.GetCustomerAuditInformation( "", "" ) ).IgnoreArguments().Return( new CustomerAuditInformation { NeedsInitialDataCreated = true } ).Repeat.Once();

}

using ( mockRepository.Playback() )
{
    var information = mockStatusCheckRepository.GetCustomerAuditInformation( "", "" );
}

Cany anyone shed some light on this? Is there a way around this?

Till next time,

[----- Remember to check out DimeCasts.Net -----]