Derik Whittaker : TDD, Development

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 -----]

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 -----]

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 -----]

Thoughts on Testing an API

Derik Whittaker — Mon, 14 Apr 2008 12:32:22 GMT

Over the past few weeks I have worked on a few products for my client that will be used as API's. These API's will be used by either their own (external) clients or other internal departments. Working on these projects made me think about testing in a little different light compared to normal testing. I thought I would share some of my thoughts and experiences that I have learned while developing and testing API style applications.

First thing to keep in mind is that testing an API is not a whole lot different then testing a product (non-API), but you do need to take a few extra steps to ensure that your code is well tested and can be easily consumed.

Find the 'Main Artery' in your code.
This may seem pretty straight forward, but finding this Main Artery is critical on your journey to testing your API. Unlink many 'standard' applications which have many entry points and exit points, API's tend to have a very few entry/exit points. This means that many of the features of the API may flow down the same artery, which provided you a huge area of risk.

Finding this pathway is also critical due to the fact that the majority of your Use Cases are likely to travel down at least part of this path and if there is any type of issues with either your code or your logic, they will crop up all over the place.

Here is a little example
Imagine you have a 2 story house, and you want to go from the garage to the second floor. When you enter the house via the garage door there are likely a few different ways to move around the first floor until you get to the stair well. However, once you reach the stairs, there is only one way to get to the second floor. The stair well in this example is our main artery. If anything goes wrong with the stairs we cannot go from the first floor to the second. Hence the need to find and test this code as heavily as possible.

Create as many 'Scenario' style Integration Tests as you can.
The best way to test your API is to not only create a solid set of Unit Tests that allow you to test your individual modules, but you also need to have a very exhaustive set of Integration Tests that allow you to run end to end slices through your API.

You want to make sure that your API functions from the outside-in as desired. The worst thing you can do is hand over your API and have someone else find an simple issue. This type of testing will also allow you to test the performance of your API, if performance is something that you may be concerned with.

When creating your Scenario tests you will not only want to test known good data and known bad data, but also test with various random data. Your goal should be to try to make your application fail, and in a bad way. Creating tests for 'known' conditions is fine, but they will not ensure success. Try to find edge cases and test as many of those as well.

Create a 'Test Application' that consumes your API as your expected consumers would.
Because your API is going to be consumed via 3rd party you should create some sort of stand alone test application for verify your API. I would suggest you create a new .Net solution and add 1 project to the solution, with this project being nothing more then a test project *** I AM NOT SAYING TO CREATE A UI APPLICATION ***. By creating the stand alone solution you will learn how much effort or pain will be involved in consuming your API. There are a few things in particular that you should look our for when consuming your API

Are they any configuration files that I need to deploy?
Are my entry points for the API clearly defined?
Do I need the consumer to reference any other assemblies besides my own?

You may find that your configuration setup is flawed, or you may find that you made too many assumptions about consumption during your initial development. I know that when I did this I was enlightened to how my API was going to be used, and allowed me to better understand how to develop future features.

Finally, by consuming your own API you have a better understanding of how it works and this will allow you to create some sort of documentation on consumption of your API that can be attached to your code. This can be huge asset to the API and can lessen the learning curve for your consumers.

The above thoughts/comments are purely created out of my own experiences, actual results may vary.

Till next time,

App.Config issues when running NUnit via Resharper

Derik Whittaker — Tue, 25 Mar 2008 13:43:00 GMT

***** Update *****
This issue is directly related to a #R 4 EAP issue. I was using build 755 and this was an issue. As of build 762, this is no longer an issue.
********************

Today I encountered some odd behavior when trying to run some tests against my configuration object. I am hoping that someone out there has some insight for me.

My issue

I have a project that produces an assembly by the name of AccessKey.Domain.Tests.dll. Because I have a app.config file in the project, the config file is renamed to AccessKey.Domain.Tests.dll.config when the project is compiled.

The problem is that when I try to access the appSettings value in the config file I am only getting nulls. For what ever reason, the .net framework thinks my file should be named AccessKey.Domain.Tests.config (notice the .dll is missing from the name).

I have verified that the framework is in fact trying to pick up the wrong assembly by checking 2 things.

System.AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
ConfigurationManager.OpenExeConfiguration( ConfigurationUserLevel.None ).FilePath

Both of these have point to using the wrong config file name. I even tried to set the value in the System.AppDomain.CurrentDomain.SetupInformation.ConfigurationFile property, but that did not work.

My Resolution (but is lame)

In order to get this to work, I simply created a config file in my test project named AccessKey.Domain.Tests.config (again, notice the .dll is missing) and set the file to be copied to the output directory at compile time.

I don't like doing this as it feels dirty as well as it is not testing my system correctly.

Does anyone have a solution for my problem. In my 2+ years of testing, I have NEVER run into this issue....... HELP!

Till next time,

Backing in Unit Tests into an existing project

Derik Whittaker — Tue, 09 Oct 2007 12:35:39 GMT

Recently I was asked about backing in unit tests into an existing project. In particular I was asked A) was possible and B) is it worth it. In short my answers to both these are Yes and Yes. However, backing in unit tests is not without its challenges. I thought today I would go express my experiences with doing exactly this and what types of hurdles I ran into.

Start off by only testing new code
When backing in tests, it is very important to accept the fact that a large percentage of your application is going to be untested. Accepting this fact will help you move forward. I would suggest that as you write new code (be it new modules, features or whatever) you write them following the TDD practice. This will be the simplest way to get the ball rolling.

Doing this is also an easy way to get other team members on board with the testing idea. I know from personal experience that when we wanted to started following TDD on a project that was 2 years in, many of the other developers thought it was a waste because we have so much that is untested. They thought it would take too much time/effort to write test for existing code. I agree with this. So only test going forward

Add tests to existing code only when changes are needed
I know I just said above to only test new code, and this is true. However, when you are making changes to existing code test those changes. Again, you don't have to try to test all the existing code, only the path ways you are adding/changing.

If you follow this, over time you will start to build a nice suite of tests that tests not only new code, but some existing code as well.

Mock as much as possible
Mocking is a great tool. I like to mock code that I don't have control over, or when I have no faith the code will work reliably. This is especially important in a project that does not have tests.

An example would be this. Lets say you are adding a new feature to an application that needs to call into some sort of calculation engine. Since this calculation engine is not tested and you have no real faith that it will work reliably, mock it. You should know that given a valid set of inputs you expect to receive a given response. By mocking this you remove all risk of the calculation engine failing thus causing your tests to fail.

*** I can hear you now, you want your test to fail when the calculation engine fails.... No you don't. Unless your test is actually testing the calculation engine, you don't care if it passes or fails. You just need to call it. ***

Take this as a learning experience
Take this time as a way to learn to write good solid tests. This will be of great benefit later in your next project. Also, you will also learn how to write better code that is more acceptable to testing (hum... sounds like another good post). Remember, in order to become good at something you must first be bad at it. But with practice you will become better and you will be a better developer because of it.

Be patient
Testing is painful at first. It is a shift in your development mind set. Be patient, it gets better. This is no different then learning anything else. It will take time, but eventually you will become comfortable with TDD and it will become second nature. You never know, you may end up like me and find it odd when you are NOT writing tests.

I hope this helps.

Till next time,

Why I believe IN and WRITE unit tests

Derik Whittaker — Tue, 02 Oct 2007 00:27:25 GMT

In my last post I think I struck a cord with some people in my post 'Unit tests taking too much time'. My intent was NOT to sound like an elitist Agilist or any else of that nature. My intent was simply to put a post out there about the misperception (in my opinion) about how writing unit tests take too much time.

I thought I would put my 'retort' on why I believe in and write unit tests.

Allows ME to write better code

I believe that when I truly follow TDD practices my code comes out simpler. I have also found, that my code tends to follow YAGNI more so then when I don't follow TDD practices.

Here is an example from my past experience. On a prior project I needed to build a 'search engine' into our app (this was not an actual search engine, more like a hunt path engine). When I first started out writing code I started out by creating all these classes and logic that I thought I would need. After about 3-4 hours of coding I was dead in the water. I was not able to solve my problem in a simple manner and I was frustrated. I decided to take a step back and start over.

This time though I started out by writing test to mimic what I actually needed. I continued to follow the principles of TDD (btw, TDD is more then just about writing tests), within an hour or so I had my solution pretty much good to go. All those classes and methods I THOUGHT I would need I did NOT. I was able to scrap about 50% of the code/classes that I thought I needed. And guess what, now I have a test suit to test my new code.

Allows ME to find more bugs during the development process

It has been my experience that I find more bugs while writing tests. This is due to the fact that I not only follow TDD, but I also do my best to implement the Fail Fast Principle. When I am writing my tests I have the ability to create tests that easily walk though the different pathways of my code (I attempt to hit 100% code coverage as well). If I were not writing tests I would have to do this via the application, and this is much more painful and it less likely that I would actually do it.

By writing my tests and testing my code during the development process I know that I have reduced my bug count significantly.

Makes ME feel more comfortable making changes

This is the beauty of TDD, I am not afraid to make any critical changes to my code because I KNOW that I have tests to verify if I screwed anything up.

Have you ever run across some code that 'you were scared' to change? If you had tests for that code I bet you would a WHOLE LOT LESS scared to make any changes. I know that I am.

A case in point for this is as follows. On a prior project a consultant I was working with needed to make changes to some 'smelly' logic. This just happened to be a week or so before a scheduled release. Beacuse he had NO confidence that the changes he would make would NOT break the application, he convinced the business to NOT make the changes. I bet you a dollar that had there been unit tests he would have been much more willing to make the changes. In this case the fact of NOT having tests may have caused the business to lose out on features it needed.

Improves MY code

Because following TDD practices forces you to write your failing code before your passing code, I tend to implement my intent much cleaner and simpler. I also know that because I am writing tests along the way my code is solid.

Allows ME to better convey intent

I know that tests are not a substitution for quality comments that convey intent, but they sure are the next best thing. It is really nice to be able to point someone towards a suite of tests to 'demo' how to use a component.

A case in point for this is as follows. A few weeks ago at work I wrote an API to allow the querying of some data via our imaging system at work. Turns out that an outside party needed to use this API for integration into on of our 3rd party applications. When he came to me asking for 'how do I use this', I simply emailed him my suite of tests. In this suite I had pretty much any conceivable use for the API. To date the vendor has not asked me how to implement the API.

Allows MY tests to be automated and rerunable

This is a nice side effect of having tests. Because we use both NUnit and CruiseControl I can run my tests on every check in. This is cool because now I (and the team) know if changes I made breaks some other part of the system. I would rather know now then before QA hits it.

The above are simply my opinion, if you don't share the same opinions, let me know.

Till next time,

StructureMap Tip: Using Concrete classes as a PluginFamily

Derik Whittaker — Mon, 23 Jul 2007 22:43:00 GMT

Have ever wanted to use a concrete class as both the the PluginFamily and Plugable (information on StructureMap's attributes here) type in StructureMap? I know I have, just today in fact (not the first time, but thought I would post about it this time) I needed to do just this. Why would I want to use a concrete class as both PluginFamily and Plugable type you may ask. Well in this case because I wanted to use DI to inject my configuration class into one of my objects (via constructor injection) and did not think it was worth the effort to create an interface.

Normally if you were use an interface as the PluginFamily and a concrete class as the Plugable, your code would look something like below.

Interface

[PluginFamily("FamilyNameGoesHere")]
public interface IFoo
{

Concrete

[Pluggable("FamilyNameGoeshere")]
public class Foo : IFoo
{

Do have your concrete class act as both you simply combine the two as such

[PluginFamily("FamilyNameGoesHere"), Pluggable("FamilyNameGoeshere")]
public class ConcreateWithNoInterface
{

Keep in mind, that when you do not use interfaces with DI, you are taking away a lot of the power and flexibility that DI provides you. But there are cases from time to time where this situation comes into play.

Till next time,

Doh, there are 4 hours I will never get back

Derik Whittaker — Wed, 18 Jul 2007 01:28:00 GMT

Today, I was working on one of my first ever (actually, it is my 2nd) WCF services. This service was meant to be pretty simple, 1 method with 4 param's. It should not take that long, or will it. To get the service started, I began by writing the library...(read more)

What I'm Learning

Derik Whittaker — Fri, 08 Jun 2007 22:18:00 GMT

This post is in response to Sam Gentile's post over at code better I'm Learning Rhino Mocks NHibernate StructureMap Policy Injection Blocks Log4Ne t (yea I know, what took so long. Answer, last few apps use the Logging App Block) MonoRail (about to start...(read more)

Technical Debt, How we accumulate it, and how we can reduce it

Derik Whittaker — Fri, 25 May 2007 14:03:00 GMT

All software projects will amass some amount of technical debt. This is not a necessarily bad thing; it is just he cost of doing business. As developers the only thing we can do is try to control/limit the amount of technical debt we build up. If you...(read more)

Learning to use Mocks and the power they provide

Derik Whittaker — Wed, 23 May 2007 11:54:00 GMT

Up until a few months ago I had never even attempted to use mocks ( NMock , RhinoMock , etc). Every time I would read about Mocking I thought to myself, this is kinda cool, but seems to be a waste of energy. At the time I saw Mocks as only a way to create...(read more)

Handling Events in Unit Tests with anonymous delegates

Derik Whittaker — Mon, 23 Apr 2007 17:26:00 GMT

Recently a co-worker of mine (Lou, smart guy… (Lou, your shameless plug)) needed to test a UI control that raised an event upon certain conditions. In order to handle this event he needed to have some way to trap that it was raised.

The solution he came up with was simple and elegant.., use an anonymous delegate.

Here is an example
// Create the UI container that is going to be tested TripZipCodeRouteSelector tripZipCodeRouteSelector = new TripZipCodeRouteSelector(); // Create the local variable to handle the anonymous delegate call bool eventRaised = false; // Wire up the anonymous delegate call tripZipCodeRouteSelector.InValidZipCodeProvided += delegate { eventRaised = true; }; // Run the code that should raise the event tripZipCodeRouteSelector.OnZipCodeChanged( zipCode ); // Assert that the event was raised and it swapped the flag on the bool Assert.AreEqual( true, eventRaised , "The event was not raised.");

I thought this was pretty cool.

Thanks Lou.....:)

Options Wanted: How do I handle my Mocks

Derik Whittaker — Tue, 17 Apr 2007 12:35:00 GMT

I am looking for feedback from the group. I am pretty new to using mocks for my unit tests and I am not sure what the standard approach in the community for usage of mocks in regards to how/where they are stored in your test application.

After refactoring some of my tests to use mocks I quickly noticed that I was littering the same mock creation code in many of the unit tests. So, the first thing I did was create a local helper method inside my test. However, as I continued my refactoring I was started to create the same helper method in many classes. After noticing what I was doing, I knew there had to be a better way to do this.

What I am thinking of doing is creating a ‘Mocks project’ that will only contain static methods that can be called (with and without construction params) to build and return a mock for a given interface. The reason I want separate class for this is because 2 different projects use the same backend, but each have their own test suite.

Does this sound absurd?

Thanks for any insight.