Tip for making AutoFixture and xUnit.net play nice

Just a quick tip, for making AutoFixture 2.1 play nice with newer xUnit.net versions:

I installed Autofixture via NuGet, which gave me AutoFixture 2.1 and xUnit 1.7, when running my tests they threw this:

System.IO.FileNotFoundException: 
   Could not load file or assembly 
   'Ploeh.AutoFixture, Version=2.1.0.1, Culture=neutral,
   PublicKeyToken=b24654c590009d4f' 
   or one of its dependencies. 
The system cannot find the file specified.


The reason is that the test runner thinks that AutoFixture needs and older version of xUnit (although it doesn't really).
The solution is to put this in the app.config for the test projects:

    1   <runtime>

    2     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

    3       <dependentAssembly>

    4         <assemblyIdentity name="xunit.extensions"

    5                           publicKeyToken="8d05b1bb7a6fdb6c"

    6                           culture="neutral"/>

    7         <bindingRedirect oldVersion="1.6.1.1521"

    8                          newVersion="1.7.0.1540"/>

    9       </dependentAssembly>

   10     </assemblyBinding>

   11   </runtime>

   12 

You'll probably have to fix up the newVersion to the exact version you have.

That's it for now.

Upcoming Events

I have couple of events coming up that I thought I'd share here: The Agile Architecture Open Space Conference and an ANUG code camp on enhancing legacy test suites.

Agile Architecture Open Space Conference
On the 29th and 30th of September a couple of colleagues and I are running a small conference under the headline of sustainable architecture in an agile world. It's an open space conference, so there's next to no official program. But there is plenty of room for in-depth discussions and networking. With the line up of attendees so far I think it'll be awesome. There are still a few spaces left, so check it out at http://aaosconf.eventbrite.com/.

Enhancing Legacy Test Suites
On the 19th of November I'll be running a code camp on the subject of enhancing legacy test suites. It'll be a longer, more in-depth and more hands-on version of the workshop on the same subject I did at SC2011. The premise of the code camp is that we see more and more code bases with some automated tests around them, but these tests are often lacking in quality. The tests are sometimes just there to cover somebody's ass, sometimes they are very tightly coupled to the implementation, sometimes they are flaky, and they almost always cover only a fraction of the production code.
At the code camp we'll dive into techniques to improve this situation, and move towards a situation where the test suite is an asset. Where the tests are not a burden to maintain, and where they provide the confidence they should.
I'll start the day by introducing a few techniques, and an example code base with some tests associated. The bulk of the day will be spent applying the techniques to the example code base through a number of iterations with tasks set be me for each one. Should be a lot of hacking fun

Developer Survey Results - Part 4

This is the forth and last post in my series summaries of the develop practices survey I ran  (the other posts are here, here and here).


This one is about practices to ensure code quality. But tool driven things. I'm less interested in the use LINT-style tools, than in the use reviews, pair programming and refactoring. so the last ones were the ones I asked about.


Asking "do you pair programming" survey says:

Yes, all the time			2%
Yes, often			6%
Yes, from time to time			19%
No, almost never			47%
No, never			18%

In other words, next to no respondents practice pairing often, and two thirds almost never or never practice it. , I honestly almost never pair myself.  Can't decide if this is good or bad.
Next question was if respondents use code reviews. The responses were:

Yes, all code is reviewed			6%
Yes, most code is reviewed			16%
Yes, some code is reviewed			27%
No, almost no code is reviewed			34%
No, never			8%

Again usage is pretty low. Now, this I do think is a waste. In my experience reviews really do work, when they are kept at the right balance between the totally informal "just discussing stuff" and the totally formal "you have to sign this before you leave".
Of the 92% that do use code reviews on at least at bit of code now and then, the types of reviews used were:

Formal reviews with formal approvals			4%
Formal reviews without formal approvals			17%
Code walk throughs			48%
Active design reviews			7%
"Hey, come take a look at this code on my screen"			72%

The weight here is one the more informal review types. Not surprising I guess. They are easy and cheap. And they can return a lot of value. Lastly I asked about a personal favorite - something I think is absolutely necessary in order keep code maintainable: "Do you use refactoring?" The responses were:

Yes, I always try to leave the code cleaner than I found it			26%
Yes, from time to time			44%
Yes, as separate tasks			10%
No			11%
Other			10%

Which is a fairly good note to end on :-)