ploeh blog danish software design
AutoFixture 3
Announcing the general release of AutoFixture 3.
AutoFixture 3 has been under way in a long time, but after about of a month of limited beta/CTP/whatever trial, I've decided to release it as the 'official' current version of AutoFixture. Since AutoFixture uses Semantic Versioning, the shift from 2.16.2 to 3.0.0 (actually, 3.0.1) signifies breaking changes. While we've made an effort to make the impact of these breaking changes as light as possible, it's worth noting that it's probably not a good idea upgrading to AutoFixture 3 five minutes before you are heading out of the door for the weekend.
Read more about what's new and what has changed in the release notes.
Thank you to everyone who helped make this happen. There have been a lot of people contributing, providing feedback, asking intelligent questions, etc. but I particularly want to thank Nikos Baxevanis for all the work he's been putting into AutoFixture. Conversely, as is usual in such circumstances, all mistakes are my responsibility.
What's new? #
When you read the release notes, you may find the amount of new features is quite unimpressive. This is because we've been continually releasing new features under the major version number of 2, in a sort of Continuous Delivery process. Because of the way Semantic Versioning works, breaking changes must be signaled by increasing the major version number, so while we could release new features as they became available, I thought it better to bundle up breaking changes into a bigger release; if not, we'd be looking at AutoFixture 7 or 8 now... And as I'm writing this, I notice that my installation of Chrome is on major version 25, so maybe it's just something I need to get over.
Personal release notes #
One thing that the release notes don't explicitly mention, but I'd like to talk about a little is that AutoFixture 3 is running on an extensively rebuilt kernel. One of the visions I had for AutoFixture 3 was that the kernel structure should be immutable, and it should be as easy to take away functionality than it is to add custom functionality. Taking away functionality was really hard (or perhaps impossible) in AutoFixture 2, and that put a constraint on what you could do with AutoFixture. It also put a constraint on how opinionated its defaults could be.
The AutoFixture 3 kernel makes it possible to take away functionality, as well as add new functionality. At the moment, you have to understand the underlying kernel to figure out how to do that, but in the future I plan to surface an API for that as well.
In any case, I find it interesting that using real SOLID principles, I was able to develop the new kernel in parallel with the version 2 kernel. Partly because I was very conscious of not introducing breaking changes, but also because I follow the Open/Closed Principle, I rarely had to touch existing code, but could build the new parts of the kernel in parallel. Even more interestingly, I think, is the fact that once that work was done, replacing the kernel turned out to be a point release. This happened late November 2012 - more than three months ago. If you've been using AutoFixture 2.14.1 or a more recent version, you've already been using the AutoFixture 3 kernel for some time.
The reason I find this interesting is that sometimes casual readers of my blog express skepticism over whether the principles I talk about can be applied in 'realistic' settings. According to Ohloh, AutoFixture has a total of 197,935 lines of code, and I consider that a fair sized code base. I practice what I preach. QED.
String Calculator kata with Autofixture exercise 8
This is the eighth post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 8 and 9. Although the kata has nine steps, it turned out that I slightly misinterpreted the requirements of exercise 8 and ended up implementing the requirements of exercise 9 as well as those of exercise 8 - or perhaps I was just gold plating.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
String Calculator kata with Autofixture exercise 7
This is the seventh post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 7.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
String Calculator kata with Autofixture exercise 6
This is the sixth post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 6.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
String Calculator kata with Autofixture exercise 5
This is the fifth post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 5.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
String Calculator kata with Autofixture exercise 4
This is the fourth post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 4.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
Comments
Also I wonder what if you have error in summing? Error will show sth. like: Expected 34212, was 19857. How do you know what numbers where generated by int generator?
Unit tests that leverage AutoFixture tends to be terser and more declarative in nature than more traditional unit tests, which tend to look more imperative. Like every other new thing, it takes some time getting used to.
That said, there are things about the String Calculator kata that makes it a less than ideal fit for AutoFixture. The problem with the kata is that it's essentially just a bunch of more or less arbitrary rules (throw on negative numbers, ignore numbers bigger than 1000, support custom delimiter strings, etc.) There's no real domain being modelled here.
If there had been a more proper domain, a refactoring phase would probably have prompted me to redesign the API and introduced a custom Delimiter Value Object that I could have requested in the test, instead of requesting a Generator. That would have made the test even terser, but also, IMO, more readable. However, I didn't want to do that in this screencast, as I was concerned it would be too much of a digression.
String Calculator kata with Autofixture exercise 3
This is the third post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 3.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
String Calculator kata with Autofixture exercise 2
This is the second post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast implements the requirement of the kata's exercise 2.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
String Calculator kata with AutoFixture exercise 1
This is the first post in a series of posts about the String Calculator kata done with AutoFixture.
This screencast sets up the Visual Studio projects and completes the first exercise of the kata.
If you liked this screencast, you may also like my Pluralsight course Outside-In Test-Driven Development.
Comments
String Calculator kata with AutoFixture
This post introduces the String Calculator kata done with AutoFixture.
A couple of weeks ago, at the Warm Crocodile conference in Copenhagen, Roy Osherove and I talked about AutoFixture and his String Calculator kata, and I decided to do the kata with AutoFixture 3 and make a series of screencasts out of it.
This series makes no particular attempt at explaining what AutoFixture is, so you might want to first acquaint yourself with some basics, such as the theory of Anonymous Variables, Derived Values, Equivalence Classes, and Constrained Non-Determinism. It might also be a good idea to understand how AutoFixture integrates with xUnit.net.
The following screencasts are available:
As a general note, I didn't focus much on refactoring in this exercise, as I didn't feel the complexity of the solution required it.
If you like these screencasts, you may also like my Pluralsight course Outside-In Test-Driven Development.
Comments
It seems you assume that the int generator always returns non-negative numbers.
Is this true and by design? why?
Thanks
In AutoFixture 3, numbers are random.
In AutoFixture 2.2+, all numbers are generated by a strictly monotonically increasing sequence.
In AutoFixture prior to 2.2, numbers were also generated as a rising sequence, but one sequence per number type.
Common for all is that they are 'small, positive integers'.