The BDD Way

Lessons Learned about the Behavior-Driven Development Process

I recently completed a week-long project with a group where we built the game Scattergories in JavaScript. It left me thinking a lot about the Behavior-Driven Development (BDD) process and Agile software development. Throughout General Assembly’s Web Development Immersive program, I’ve felt that BDD and the Agile process have been things I’ve mentally understood and have been on board with but haven’t deeply understood. I think they can only be learned by experience. After having done my first complex project with BDD, I still don’t think I deeply understand it, but I did learn a few things I’d like to pass on:

1. After sinking many empty hours into researching how to write a test that you don’t know how to write, don’t just abandon the BDD ship.

I think it really is better in the long run (or even short run) to get those tests written. With Scattergories, we used a lot of AJAX requests which were messing up our tests due to the asynchronicity, so we shelved feature tests. I cringe when I think about how many times I manually filled in those twelve blank answer forms with dummy data. Time invested in the tests in the beginning would have saved a lot of tedium.

Additionally, since testing is itself its own language, I wish I would have used the challenges of the project to improve my testing skills. You can’t get good at something if you always just put it off. Since I’ll probably encounter the same scenarios I struggled with this time again at some point in the future, I wish I would have just invested the time in learning those skills now- even if it had taken a full day.

2. It’s useful to think of your application existing at the model level, not the user interface level.

During the project, my teacher PJ remarked to me that we should be able to play our game in the console. An app is the actual code that makes it run, not the way you see it. So the model-level code is what you begin creating (and thus what you begin testing).

That was really helpful to think about. In class, we had actually seen this principle through a couple specific exercises, but I apparently failed to internalize the lesson. We built versions of hangman and tic-tac-toe where we first built the models’ Javascript code along with Jasmine tests, and then we wrote JQuery to hook up the UI.

With Scattergories, my group didn’t quite stick to this very clear approach from the outset, which necessitated us doing a major overhaul at one point. The problem was we got distracted by the fact that we would eventually need to sync the game’s client-side data with the server, which led us to building out those parts of the UI before all the game’s model-level data and behavior were firmly created in a BDD-way. This resulted in code with an entangled model/UI design, which had no separation of concerns and that was just messy. Plus, since we didn’t figure out how to test AJAX and since our model/UI hybrid was relying on AJAX, certain aspects of our model remained untested. Double fail (until we fixed it all ☺).

3. The testing process, if used, keeps you focused on one problem at a time.

To organize ourselves, our group used the awesome Pivotal Tracker with user stories. Usually I find user stories very helpful, but this time their value wasn’t as strong. Thinking back, I feel like our group sometimes had trouble knowing what we were all working on, or even deciding what different people could be working on at the same time. This could be due to the nature of the specific game we were working on, but it also makes me think of tests.

When I think about things in the project I used BDD to create, it was very clear to me at each step of the way what my task was: to get the test to pass, then to write a new test. What test should I write? I had user stories to tell me. But without tests, it was a little more of a free-for-all. For myself at least, I remember working for periods of time where I was just sort of… working. I wasn’t following any kind of guidelines or process- just chasing whatever issue popped up in the moment, sometimes checking in with the rest of the team to see where they were. This approach did work…it just wasn’t nearly as easy or as focused. And instinct tells me that if the project had been larger or needed to scale, it couldn’t have gone on much more than it did.

In general, I had an amazing time working on Scattergories. My group got along very well, and at each step along the way, I think we did a pretty good job of planning in small cycles and breaking problems down into smaller parts. Abandoning testing seems to have been a key reason behind some of the troubles we encountered along the way however. I cherish the things I learned from the project. It makes me think how sometimes, when things don’t go perfectly or the way you want, you often learn the most valuable lessons.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.