I have heard many times that tests are like documentation for other developers. The argument is that formal documentation (word documents, spreadsheets, etc.) rarely stays in sync with the current state of an application. Therefore, unit tests act as a kind of up to date documentation (provided that the tests are all passing, of course). Tests tell developers who are not familiar with the code, how an application should work and what the expectations are. But consider this test:
[TestFixture]
public class when_user_is_logging_in
{
[Test]
public void only_three_login_attempts_are_allowed()
{
ILoginView view = MockRepository.GenerateStub<ILoginView>();
view.Stub(x => x.User).Return("bad");
view.Stub(x => x.Password).Return("bad");
ILoginService loginService = MockRepository.GenerateMock<ILoginService>();
loginService.Expect(x => x.UserExists("bad", "bad")).Return(false);
LoginPresenter presenter = new LoginPresenter(loginService);
presenter.Initialize(view);
view.Raise(x => x.TryLogin += null, this, EventArgs.Empty);
view.Raise(x => x.TryLogin += null, this, EventArgs.Empty);
view.Raise(x => x.TryLogin += null, this, EventArgs.Empty);
view.AssertWasCalled(x => x.Close());
}
}Right away it’s pretty clear that “when a user is logging in, only three login attempts are allowed”. But things quickly go south after that. What mocking frameworks give us in convenience, they sure take away in readability. Regarding the above example - it’s written using Rhino Mocks 3.5. Many developers not familiar with mocking may be surprised to learn that this is actually the “good” syntax. Things used to be a heck of a lot worse. However, I still think that there are some things that could be done to clean these tests up, while still adhering to spirit of “tests that act like documentation”. My goal here, is to do this with as little ceremony as possible. I am not interested in writing a whole lot of new code in order to achieve readability. I just want to explore some simple ideas. When looking at the examples here, try to consider that there may be 10 or more additional tests which are not being shown. This will give you a better gauge as to whether the effort expended here is really worth it.
The Clean Up
ILoginView have User and Password properties that needs to return different values depending upon the test. To clean up the current implementation, we could do something over-the-top, like this:
// add this method to test class
private static ILoginView CreateLoginView
{
get
{
return MockRepository.GenerateStub<ILoginView>();
}
}
// add internal class to hold extension methods
internal static class when_user_is_logging_in_extensions
{
public static ILoginView WithUser(this ILoginView view, string user)
{
view.Stub(x => x.User).Return(user);
return view;
}
public static ILoginView AndPassword(this ILoginView view, string password)
{
view.Stub(x => x.Password).Return(password);
return view;
}
}
// Now, I have a readable fluent interface
ILoginView view = CreateLoginView.WithUser("BADUSER").AndPassword("BADPASSWORD");
Readable, sure, but seriously, that’s a lot of code. All of the convenience of using Rhino Mocks is lost. To compromise, I would probably just do something like this:
// in test class
private static ILoginView CreateLoginView(string withUser, string withPassword)
{
ILoginView view = MockRepository.GenerateStub<ILoginView>();
view.Stub(x => x.User).Return(withUser);
view.Stub(x => x.Password).Return(withPassword);
return view;
}
// in test
ILoginView view = CreateLoginView("BadUser", "BadPassword");
Here, I will let the method name, parameter names, and IntelliSense act as documentation. Like the last example, it requires a bit of code, too, but in this case ReSharper handles the Extract Method for me. Renaming CreateLoginView to create_login_view makes the IntelliSense story even better (in my opinion), but I will leave that alone for now.
For the login service, I will use the same technique:
// in test class
private static ILoginService CreateLoginService(bool shouldAuthenticate)
{
var loginService = MockRepository.GenerateStub<ILoginService>();
loginService.Expect(x => x.UserExists("", ""))
.IgnoreArguments()
.Return(shouldAuthenticate);
return loginService;
}
// in test
ILoginService loginService = CreateLoginService(false);
To finish up, I will add a few extension methods by creating an internal static class at the bottom of my test file:
internal static class when_user_is_logging_in_extensions
{
public static void PushOkButton(this ILoginView view)
{
view.Raise(x => x.TryLogin += null, view, EventArgs.Empty);
}
public static void ShouldBeClosed(this ILoginView view)
{
view.AssertWasCalled(x => x.Close());
}
}
With all of the changes in place, my test now looks like this:
[Test]
public void only_three_login_attempts_are_allowed()
{
ILoginView view = CreateLoginView("BadUser", "BadPassword");
ILoginService loginService = CreateLoginService(false);
LoginPresenter presenter = new LoginPresenter(loginService);
presenter.Initialize(view);
view.PushOkButton();
view.PushOkButton();
view.PushOkButton();
view.ShouldBeClosed();
}
I am not advocating that anyone go to this trouble; context, preference, and discretion must be considered. However, I think there is great value in having readable tests. For some, the starting example might be perfectly readable. For others, not so much. As with everything, take what you like and leave the rest.
When we talk about application extensibility, we are often concerned with the structure of the code itself. Following known design principles and patterns and using techniques like inversion of control can be the foundation of a flexible, extensible, and testable code base. However, these concerns happen at compile time and are mostly static (plug-in style architectures being somewhat of an exception). In many large applications with complex business rules, there is often a need to modify a program while it is running. Searching “business rules engine” will give you no shortage of hits, but I think these types of solutions are, for the most part, not flexible enough. In this developer’s humble opinion, nothing is more flexible than code. So, if you can stop pretending that your end users “might want to change a thing or two on their own”, then you can stop pretending that code is a bad thing (I say this facetiously:) note to self: must write a rant about those who think code is bad).
I have written about how easy it is to compile C# at runtime before. I used this technique on a former project to create a “formula engine” for calculating bid-related things like mark-up, transportation costs, discounts, and so forth. I should note that these formulas were never meant to be written by end users, but rather, another developer. During one of several design sessions for this part of the application, we were made aware that formulas required a lot of context and that they could change rather frequently. Dynamic compilation proved to be a good solution and the foundation for the whole thing was coded in two days. There is nothing better than showing your client, who thought a feature would take 2 months, a working prototype in 2 days.
Embedding a Scripting Language
As it turns out, it is even easier (and more flexible) to embed a DLR language into a .NET application. My personal favorite is IronPython, but the following steps should be similar for other DLR languages. The first thing you need to do is references to the following assemblies, which are included with the DLR:
- IronPython
- IronPython.Modules
- Microsoft.Scripting
- Microsoft.Scripting.Core
Once you have added these references, it is relatively easy to start executing IronPython code. Here is a simple class that I used to test out some ideas for this article:
public class PyEval
{
private ScriptEngine scriptEngine;
public PyEval()
{
scriptEngine = Python.CreateEngine();
}
public object Execute(string yourPythonCode)
{
StringBuilder script = new StringBuilder();
script.AppendLine("import clr");
// additional imports would go here
script.AppendLine(yourPythonCode);
return scriptEngine.Execute(script.ToString());
}
}At the most basic level, the only thing required is an instance of ScriptEngine. Code can be executed by calling the Execute method. One item of interest is line #13. Here, the script is being modified before execution so that CLR extensions are available within the execution context. You will add additional imports to reference other parts of the .NET framework or assemblies within your application. The IronPython tutorial has plenty of examples on interacting with the CLR so I am going to skip that discussion.
Scope
Things get interesting when variables from your application are made available to the script. This is done using ScriptScope, and is a very straightforward process. Here is the class from the last example with a few modifications. You’ll have to use your imagination a bit to wash away the hard coding, but you should get the idea:
public class PyEval
{
private ScriptEngine scriptEngine;
private ScriptScope scriptScope;
public PyEval()
{
scriptEngine = Python.CreateEngine();
scriptScope = scriptEngine.CreateScope()
}
public object Execute(string yourPythonCode)
{
StringBuilder script = new StringBuilder();
script.AppendLine("import clr");
// additional imports would go here
script.AppendLine(yourPythonCode);
scriptScope.SetVariable("category", "drillbit");
scriptScope.SetVariable("cost", 400);
scriptScope.SetVariable("quantity", 1);
return scriptEngine.Execute(script.ToString());
}
}Now, your script will have access to variables named category, cost, quantity:
def CalculateDiscount():
if (category == "drillbit") and (cost * quantity > 399):
return (cost * quantity) * .90
else:
return cost * quantity
CalculateDiscount()
What is not apparent thus far is how this is all hooked together within an application. What I have done in the past (since I have been doing rich clients exclusively) is to embed the SharpDevelop editor into my application, which supports IronPython. Scripts are loaded and saved to a database. Fundamentally, this is all there is to it.
The primary challenge is to define the parts of your application where you want to make scripting available. It’s always good to have a specific context and then write explicit code around that concept. One example that comes to mind is a pricing engine for an online retailer that calculates discounts based on certain conditions - which are constantly changing of course. This is a specific place in some application that has highly defined boundaries.
Another idea that I am planning on exploring in the near future is extending this concept to DSL’s. I haven’t done any investigations yet, but I am wondering if there would be any benefits to creating a DSL using IronPython and then making that DSL the primary scripting tool for an application. If the focus was tight enough, I imagine it would be possible to create something simple enough for a power user to engage in:)
Practice Material
I am hosting regular coding dojo's (group practice) and doing regular code kata's (solo practice). So, I am always in the need of new material.
Here is my current list of "go to" sites when I am looking for a programming challenge. If you know of any of others, please send them my way:
1. UVa Online Judge
2. TDD Problems
3. Ruby Quiz
4. Top Coder
5. Project Euler
6. CodeKata
7. SPOJ
Some other folks doing coding dojo's
If you want to read about coding dojo's, you are definitely going to want to check out these bloggers:
1. Mark Needham
2. Ivan Sanchez
3. Danilo Sato
Update: This post is describing writing code within the context of a "coding dojo" where everyone gets 7 minutes at the keyboard. During that 7 minutes the person writes a failing tests, makes it pass, and then refactors.
I have seen many people get tripped up on what to name stuff. Should we call it this? Should we call it that? What is the perfect name for this class? What is the most expressive thing I can call this variable? Does this method really describe what I am doing in an expressive yet succinct manner? Hmmm, this name just doesn’t resonate with me.
Stick and move, people! Go, go, go, go, go!
Forget about the names, just make something up and go. If need to, borrow from my list of names:
1. lsjhdsd
2. NarNar
3. SomeSuchThing
4. x
5. y
6. i
7. j
8. sometimes k
9. stuff
Just start writing the code. You should continually be refactoring as a part of the TDD cycle, so worry about names later. Don’t stop the flow because your looking for the perfect name. You’ll arrive at that soon enough if you just keep going.
Date: Thursday, May 7th
Time: 6:00PM (coding will begin at 6:30PM sharp)
Venue/location: Houston, TX - Microsoft facility (the same room used by HDNUG | directions)
Food/sponsor: TBD
Focus: Practice Test-Driven Development
Challenge: will be announced at the dojo (but we will be using C#)
Bring a laptop with Visual Studio 2008 and NUnit!
Full details here: http://houstonaltnet.pbwiki.com/Coding-dojo
If you are interested in attending please register (so we know how much pizza we will need):
http://www.nerddinner.com/338
I have made a number of observations about developers lately. One thing I have noticed is that many developers are not comfortable talking in the abstract. They seize onto specific, minute details, and hold on for dear life.
For instance, making a statement such as “well, conceptually it is like Subversion” will 9 times out of 10 lead to a discussion where everyone is nitpicking the finer points of Subversion for the next hour – when all you really wanted to talk about was patterns for offline concurrency.
(Side note: It’s things like this that have caused me to stop paying attention to the DDD and ALT.NET list. Seriously, delving into the minutiae of the Repository pattern or MVP for weeks on end does nothing for me, personally)
Another thing I have noticed from our coding dojo’s is that “doing the simplest thing that works” is almost beyond comprehension for many people. The tentacles of complexity have a relentless grip on the developer brain, it seems.
During part 2 of our “Game of Uno” coding dojo, we arrived at a point where we needed to shuffle the deck of cards. Now, holy crap, you would not believe the conversations that ensued. I turn my head for one second, and the next thing I know there is UML on the wall and I am being told that we need a randomizer STRATEGY that will be used by the CardShuffler (because a Deck of cards does not shuffle itself, you know). This ate up most of our 2 hours.
By my estimates, worst-case scenario, this should have taken roughly 14 minutes (each turn at the keyboard is time boxed to 7 minutes).
More than once, I have heard “I know how to do this. First, we do blah blah blah. Then we do blah. Then blah blah.” The tendency is that instead of doing steps A, B, and C, folks just want to jump to Z and then go out for some drinks and talk about their panther-like coding prowess.
Now, this would be great if the point of the coding dojo was to actually win (or finish, or whatever). But the point is to practice TDD:
1. Write a failing test.
2. Do the simplest thing you have to do to make it pass.
3. MAYBE refactor.
4. Next person is up.
Chop, chop. I want to get as many people on that keyboard as possible.
Many people don’t understand that “the simplest thing that works” means that it works for the current test. That is, for the current state of the code base, it is good enough. And yes, sometimes that means hard coding “return 1;” in order to get a test to pass.
I have never seen such huffing and puffing when I tell people this.
“Well, what the hell is that going to do? That won’t work.”
Correction. It won’t always work. The point is that it works for right now, for the code we actually have. We will continue to write tests which will force us to eventually change and evolve the code. And by doing baby steps, we will arrive at a simple, elegant solution that may not have been apparent at first.
(vol. 1, issue 1)
Lately, I have been participating in a lot of coding dojo's. The dojo's that I have organized have had one ultimate purpose thus far - to practice test-driven development. However, I think the format is conducive to many different kinds of practice. For instance, I see no reason why a coding dojo could not be used as a way to practice Scrum or learn about refactoring or design patterns. Plus, it's a great excuse to get people together. When the ALT.NET crowd talks about how we can bring our practices to a larger audience, I want to yell, "This is how!" This is pure goodness.
Our coding dojo's have been done Randori Kata style. Essentially, this is pair programming and TDD, using a projector. The pair at the keyboard is constantly being rotated in and out with new people. We try to get everyone to participate no matter what the skill-level. Keyboard time is boxed in two ways: you get 7 minutes or one TDD cycle - write a failing test, make it pass, refactor.
Now the idea of coding in front of a group of people can be intimidating, I admit. I am scared to do it, but I think that's why I like it so much. It's also why I think it's important to maintain and encourage a friendly atmosphere. We are engaging in this practice not just for learning. We do it to teach as well, so mutual respect is crucial.
What makes it easier for me to participate is the TDD aspect of the practice. We take baby steps. No one gets a chance to write boat loads of code. You may be a Level 20 Code Wizard, but the format of the dojo will not allow you to beguile us with your wicked code spellz. We are just doing the next thing that we need to do, taking very small steps forward. Then we switch places. I have learned so many things about test-driven development by doing this simple practice.
I need to stress something. Everyone has something to contribute. In fact, this very night, it hit me like a ton of bricks. The least experienced person in the room says, "but that's not the simplest thing that could work." Given the context (and you'll just have to trust me on this) it was a real Zen moment.
Now here's some back story (and I apologize if this post is starting to read like the Memento script)...
I started a monthly coding dojo at my company last December on a lark. At the time I was reading all of these rad blogs where awesome people were talking about the awesome things they were doing. Seriously, I found myself getting a little jealous. Houston is such a large city, both people- and area-wise that forming communities here does not come as easy as it does in places like Austin. But you know what? I decided that its up to me to help create the community that I want to be apart of. By the power of Grayskull, it's working.
Since, I have been talking to quite a few people outside of my company that want to participate in coding dojos, too. The idea of developers getting together for mindful practice is appealing to many people, it seems. We'll be talking about it at the Houston ALT.NET Geek Dinner next week, and I am really hoping that I can help get something going on a larger scale. I will definitely be writing more on this topic in the future and sharing my lessons learned.
Until next time...
Coding Dojo Tip: Coding dojo's are lo-fi. You need a laptop, a projector, and a few people willing to learn and share. Skip the projector and run a 4-5 person dojo at a Starbucks.
Just got back from the planning session for the first ALT.NET Houston Open Spaces Conference. I have never been to an Open Spaces event before and after attending the planning session, I have to say, I am really excited. The topics are frigging sweet, plus I got to meet quite a few people that I have been wanting to meet for a long time. No time to drop names, but I will say that the best ALT.NET blogger's live in Texas :) Oh and the guy from Switzerland it really cool, too.
I was really nervous about presenting my topic. I went into the circle and said something like, "I am J.P. and I am interested in collaborative computing, mentoring, learning from my peers...and I want to talk about coding dojo's."
I waited a few moments for laughter and the hurling of rotten tomatoes...but none came. I didn't expect my topic to get many hits, but it did. Eventually, my topic was merged in with several others:
1. Rod Paddock's topic on increasing the adoption of Agile.
2. Alper Sunar's topic on learning and teaching.
3. Peter Seale's topic around being overwhelmed with so much to learn in our profession.
(incidentally, I dared Peter to introduce a SharePoint topic but he wouldn't take the bait.)
You might not think it, but "coding dojo" covers all this stuff. Stay tuned.
I was hanging out a monthly gathering after work that we call the “Architecture Roundtable”. It’s a grand name for a small group of people that just like to get together and talk about code once a month. My colleague, Kevin Lee, gave an excellent presentation on DDD. We only had enough time to scratch the surface, but we did get a lot covered.
After the meeting, we talked about coming up with a common domain that could be used as a backdrop for some of our future discussions and explorations. So, as I went home I started to mull this over.
It seems as if every other day, someone is looking for a new domain because they are tired of modeling blog engines and ecommerce sites. That’s when it hit me:
Maybe I should pick a domain that actually requires some investment in time and effort to learn.
Why the hell would I do that? Well, I like to write code for fun, so am thinking that maybe there is some value in learning a domain for fun, too, and practicing some DDD (since I can’t do much of that during the day job). Believe it or not, I am one of “those” people that actually does this type of work because I think it’s fun. Crazy, I know. Anyway…
Isn’t a big part of DDD learning a new domain and developing an ubiquitous language with the domain experts? It seems to me that just using the patterns from the Evan’s book to write code is just a small part of what DDD is really about.
Would I be over-reaching if I said that the patterns in the book are the least the book had to offer? Maybe. But sometimes I tend to think so. Some of the more interesting things in the book (to me) are ideas like Bounded Context and the dialogues between the developer and the domain expert - the stuff that deals with the how of it all – the process. To me, the patterns have always been a “this is how I did it” kind of thing – not some all inclusive how-to catalog or step-by-step guide. People want step-by-step guides for DDD. There aren't any.
I really don’t care about how you have implemented your Repository or where you put your validation code. Is your code flexible, adaptable, and maintainable. That’s what I care about. How did you and your users come to speak the same language? What insights did you gain into your domain and how did they come about? How did that affect your design? That’s the stuff that matters to me.
So, I am off in the search of a domain to learn.