Recently I lost several team members from my team. As a result, suddenly there is all this top-of-the-line hardware lying around. Of course, I can’t let good hardware sit there and rot! So now I have the developer’s dream environment.
You are looking at my quad-core, 64-bit, dual-boot system with 4 20″ flat panels and 8 GB of RAM. Synergy let’s me use one mouse and one keyboard to control both machines. Now that’s hot!!
On my current project I was introduced to Behavior Driven Development. When I first heard of BDD, I thought, “Is BDD any more than a new way to name your test methods? What’s the big deal?”
Here’s a simple unit test class that I might have written in the past:
[TestClass]
public class EmployeeTests
{
[TestMethod]
public void LastNameRequiredTest()
{
}
[TestMethod]
public void BirthDateCannotBeInFutureTest()
{
}
[TestMethod]
public void LastWidgetDateTest()
{
}
}
When I would write a test like this, the goal was to make sure that the code that I had written was working (I normally wasn’t doing TDD when writing these tests). Now there’s nothing wrong with that, let’s say that my code coverage was good, and things are good.
A BDD-style set of tests would look more like this:
[TestClass]
public class Given_an_Employee
{
[Setup]
protected override void Before_each_test()
{
}
}
[TestClass]
public class When_validating_an_Employee : Given_an_Employee
{
[TestMethod]
public void Then_the_LastName_is_required()
{
}
[TestMethod]
public void Then_the_BirthDate_cannot_be_in_the_future()
{
}
}
[TestClass]
public void When_an_Employee_makes_a_widget : Given_an_Employee
{
[TestMethod]
public void Then_the_LastWidgetDate_should_be_set_to_today()
{
}
}
Whoa, what’s with all the classes and underscores and all that! Put your preconceived notions aside and let me explain. :)
First, let me explain why TDD is good. I think that these points illustrate this best.
1. The developer starts writing unit tests around their code using a test framework like JUnit or NUnit.
2. As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work.
3. At some point the developer has the insight (or is shown) that writing the tests before writing the code, helps them to focus on writing only the code that they need.
4. The developer also notices that when they return to some code that they haven’t seen for a while, the tests serve to document how the code works.
5. A point of revelation occurs when the developer realises that writing tests in this way helps them to “discover” the API to their code. TDD has now become a design process.
6. Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behaviour rather than testing.
7. Behaviour is about the interactions between components of the system and so the use of mocking is fundamental to advanced TDD.
First you begin to write tests because you want to make sure your code works. But as you get into TDD, you realize that TDD really can be more about design than testing. If you can define acceptance criteria up front, you will be forced to think about what your code is going to need to do and design it accordingly.
BDD takes the next step. First your tests were just testing your code, then they were designing your code, and now they are describing what the code is doing. This is where the weird class and method names come in. Let me write out those tests again, translating it from C# into real world language.
Given an Employee, when validating an Employee, then the LastName is required and the BirthDate cannot be in the future. When an Employee makes a widget, then the LastWidgetDate should be set to today.
Here is where the light bulbs clicked on for me. My tests aren’t just testing my code, they are telling a story. Imagine if you were taking this code over from me and you wondered, “What is important about an Employee?” You could look at my tests and you would know exactly what is important about an Employee. You would immediately know what all of the acceptance criteria were for working with an Employee. So now you can go and change my code and have a good sense of what I was trying to make my code do!
I think by now you can see how TDD and BDD will go hand in hand. It should go something like this:
1) You get your requirements. In the requirements are a list of business rules or acceptance criteria.
2) You write your tests (or at least the classes and methods). Now you’ve translated those business rules and acceptance criteria into tests.
3) You write your code. You already have a suite of tests that you can run to know if you succeeded!
Of course, you may go back after the fact and write even more unit tests that focus on testing more granular parts of your implementation than just the overall business rules.
If you don’t like all the funky underscores that I put in the class and method names, then that’s fine. That’s just how we did it on our project (it’s all this guy’s fault). I like them because it really does help the names to read more like normal human sentences, which is much more valuable that I had originally thought.
TDD and BDD are a definite paradigm shift for a lot of people. But once you get used to it, you will never go back.
I’ve had lots of positive responses to my last post from other people that were involved in the original discussion. I just wanted to say that I was not the least bit offended by anything that was said by anyone in the original meeting. I don’t think that I could ever be upset at anyone for disagreeing with me on technical issues.
One thing that I really like about software development and architecture in general is that every project is a new challenge with new requirements that will affect how you architect a solution. So we need to be able to evaluate each situation and then evaluate what architecture fits the situation best.
This is why having discussion and disagreements is good. None of us know it all, and we can all learn from each other. My goal is not just to learn what ORM to use, or how to use WCF, or anything like that. I want to learn how to evaluate each situation so that I can design the system appropriately and use the tools that will help me get the job done.
Today in a meeting we had a big debate about project architecture, anemic domain models, SOA, and other kinds of good stuff. Seeing that I was in the minority arguing against lots of really smart people I should answer the call and defend my ideas. :)
The question that started the discussion was, “Does SOA lead to the anemic domain model anti-pattern?” This issue has been debated in the altdotnet forums recently.
First, a little about the architecture of my project. We are writing a Windows Forms app that talks to a middle-tier using WCF and then saves to a SQL Server database. Our layers go something like this:
User Interface (controllers, views)
Service Agent (helps controllers talk to web services)
—- service boundary —-
WCF services
Business Logic
Data Access (LINQ to SQL)
————————–
SQL Server
LINQ to SQL generates all of our entity objects and these entity objects are used on both sides to the wire. Our web services are not exposed to the public and our Winforms client is the only app consuming them.
Here are the issues that people have with this:
Sharing the entity objects on both sides of the wire violates SOA tenets because it introduces tight coupling between server and client.
Sharing the entity objects on both sides does violate SOA tenets. But in our case, what we’re doing is not SOA! Wikipedia defines SOA as:
Service-Oriented Architecture (SOA) is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes.
Notice the part about applications exchanging data with one another. We are not exposing our web services to anyone other than our client. We have total control of both sides of the wire. Just because I’m using web services in my app does not mean that we have a service oriented architecture! So why should I create different entity objects for each side of the wire along with DTOs and translation classes? What benefit does that give me?
Sure, sometimes you add properties to entity objects just to help you display something in a grid. And sometimes you have properties on an entity that you will never need on the client side. And theoretically there is a situation where you may want your entity object on the client to be structured differently than they are on the server for some reason. But are any of these good reasons to create new layers and create more code that I have to maintain?
I’ve worked on projects that have had separate entities for the client and server (with DTOs and translation in between). This was quite painful. Every time I had to add a new entity object with corresponding services and UI screens, I had to add 13 files to the project. 13 files!! This was before I even wrote any unit tests. I spent more time writing plumbing than anything else.
One day when I was working said project I picked up what looked like an easy bug. I had to add 2 fields to a database table and then add them to a screen. No fancy logic, no validation. It took me 20 minutes! All I was doing as was adding two properties to a screen! These types of things should be easy.
On my current project, things go much faster. I can drag my database tables onto the LINQ to SQL designer and immediately I have my entity objects created and I can load and save them to the database. I can immediately go and start writing code that has business value. I have to create 4 fewer classes for each entity now (no client entity, no DTOs, no translation code). I’m not hand-writing my entities and mapping files because these are generated for me. Sure, they’re not true POCO entities (although you can do this with LINQ to SQL if you don’t want to use the generated code), but I don’t think that it’s worth throwing away the generated code just so that I can write my own POCO entities (read: plumbing).
There are some cases where we still need DTOs to load and save data in complex situations, but we don’t spend the time doing it until we need to.
Like I said before, all of my web services are only consumed by our client. If another application or someone outside of my team wanted to consume my services, I would create a new service and use DTOs and translation so that I don’t tightly couple my domain model with outside consumers. Now I’m doing true SOA! But I don’t spend the time doing all of the extra work until I need to do it.
Because LINQ to SQL generates our entity objects and we use these throughout the app, we don’t have a rich domain model and our entity objects map one-to-one with database tables.
Sure, I admit that having entity objects map one-to-one with database tables isn’t always “ideal”, and LINQ to SQL doesn’t handle many-to-many relationships that well. But honestly, it’s not that bad. This doesn’t always sit well with the Domain Driven Design crowd, who say that you should start by creating your business objects and that the primary focus should be on the domain and domain logic. Certainly these are good concepts, and I’m not saying that DDD is a bad idea at all. If we were using NHibernate instead of LINQ to SQL we could make our business objects more like business objects and less like database tables.
My point is this — there are situations where Domain Driven Design is good (complex domain designs). But keep in mind that the goal is to deliver a working piece of software (that is testable and maintainable and all that). No one will care that your business layer is super-elegant if you don’t get done on time. In that case, my “good enough” business layer trumps the more elegant business layer that took longer to develop (in fact, I’d guess that with DDD you would still have the majority of your business objects map one-to-one with database tables anyway). Remember, the architecture is not the deliverable.
The business objects do not have any behavior in them, all of that is in the business logic layer (the anemic domain model anti-pattern), and this is not good object-oriented design.
Yes, the fact that my business objects don’t have the logic in them is an example of the anemic domain model pattern. You got me on this one. But really, how bad is this? Sure, you don’t know to look for GetOrdersForCustomer() in the CustomerLogic class or the OrderLogic class. But what’s the worst that can happen? Someone writes the code to fetch this stuff twice?
While I would love to have the business logic encapsulated in my business objects, I also don’t want to send all of the validation rules and server logic over to the client, and I don’t want to switch to DTOs and client entities just to resolve this problem. So I’ll live with the anemic domain model for now. Honestly, most of the complaints I’ve heard is that it’s annoying to have the logic in separate classes, but I haven’t heard anyone say that it flat out doesn’t work.
In summary…
Remember, what is our goal — to deliver a piece of software on time, that meets the business needs, and is maintainable. On my current project, we delivered on time (our first release was done a month ahead of time), we were able to spend more time writing code that meets a business need (vs. writing plumbing), and our code is quite maintainable in my opinion (18 different developers have worked on it, and we just wrote our 3000th unit test today). Obviously, I cannot take most of the credit for this because the people writing the code are the main reason for the success. But I like to think that the architecture that we’re using helped us do it.
Discuss!
The Todd tagged me so I guess that means I’m it.
How old were you when you started programming?
I don’t exactly remember, but I think I was around 9 or 10. We had an Apple IIe with a green screen monitor. I don’t remember how I discovered that you could write programs on it, but I did.
How did you get started in programming?
See above… that was when I was younger. Once I got out of grade school, I spent all my time playing sports or hanging out with friends so I didn’t spend that much time on the computer anymore. When I graduated high school, they told me I had to pick a major and computer science sounded better than anything else out there.
What was our first programming language?
BASIC! Lots of GOTO and GOSUB. Ick.
What was the first real program you wrote?
I had an internship in college and I worked for a small consulting firm. The main project was a commercial video editing program written in C++ called CineStream. It was pretty cool getting to work on software that actually sat on shelves, and $11 an hour is a lot when you’re a college student!
What languages have you used since you started programming?
BASIC, C++, Java, PHP, Perl, Javascript, C#
What was your first professional programming gig?
I worked for Thomson Tax and Accounting (back then it was called Creative Solutions), where we wrote tax and accounting software for accounting firms. I lived in the C++ world for a couple years and then got to make the jump to C#/.NET. It was a fun place to work… we had a basketball court in the parking lot, so we had leagues after work and played often during lunch. More workplaces need stuff like that.
If you knew then what you know now, would you have started programming?
Heck yeah! My one reservation about going into computer science in college is that I was afraid that I would end up in some cubicle for the rest of my life and not talk to anyone all day. Now I sit in a room with 12 other developers every day. Quite the opposite of what I was afraid of. Some people say that computer geeks are anti-social, awkward people. I guess it just depends on who you’re talking to, because the software developers I know are a pretty social bunch.
If there is one thing that you learned along the way that you would tell new developers, what would it be?
You can always learn something from anyone, so don’t put other people down or think you’re better than them because everyone can teach you something (sometimes, they’ll teach you what not to do!). Find other smart people and learn everything you can from them. Put others first before yourself. Don’t throw your people under the bus. A lot of this stuff really applies to life in general, not just life as a software developer.
What’s the most fun you’ve ever had programming?
My favorite feature I’ve ever had to work on was a custom report generator for a financial analysis application. Basically I had to write a custom spreadsheet control that could do Excel-style formulas and lots of custom financial analysis functions. It was quite a challenge. But I’d have to say right now I’m having as much fun as I ever have in my career because I sit in a room with 12 other developers who know what they’re doing and we have a lot of fun doing it (even if I don’t write much code anymore).