TDD

How I Learned to Love TDD

I remember one of my CS professors at Calvin starting class one day by talking about TDD (Test Driven Development). “Write your tests first, then write the code to make the tests pass,” he said.

At that point in my programming career, TDD and unit testing in general just seemed like extra boilerplate code required to make my professor happy. If my assignment didn’t have tests (or good enough tests), I got a bad grade. However, I rarely, if ever, actually followed TDD principles when I was on my own—it just didn’t make sense to me. Write the code, test it manually, and then solidify it with some automated tests—that sounded like a better use of my time. Read more on How I Learned to Love TDD…

Bye-Bye, Sinon – Hello, testdouble

UPDATE: Justin Searls, the author of testdouble.js sent me an email with some notes on this post. I’ve added some his comments below to provide some additional context.

I’ve been working in JavaScript-land for the last little while, writing lots of Node.js code. Since I practice TDD, I’m always trying to keep my eye on the best new ways to test JavaScript code. Read more on Bye-Bye, Sinon – Hello, testdouble…

TDD in a REPL

REPLs (Read-Eval-Print-Loops) are often billed as a great place to experiment and learn a language or a framework. They provide a very tight feedback loop. However, it can be difficult or time-consuming to extract the knowledge gained from a REPL and include it in your source code. I’ve hit the up arrow many times in Ruby’s pry, trying to find the specific input I wanted to copy. And don’t get me started on dealing with multi-line input. Thankfully, the developers behind F# came up with a clever way of dealing with this problem. Read more on TDD in a REPL…

More Typing, Less Testing: TDD with Static Types, Part 2

In part 1 of this post I claimed it’s easy to test-drive our way into a poor design. We looked at some techniques for using types with TDD, but the examples were simple. Today I’ll walk through Kent Beck’s Money example showing where the design fails and how it can be improved with types. Read more on More Typing, Less Testing: TDD with Static Types, Part 2…

More Typing, Less Testing: TDD with Static Types, Part 1

I learned test-driven development from Kent Beck’s book Test-Driven Development By Example. It’s an excellent introduction that whets the appetite for one of my other favorites, Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce.

Both of these books have a blind spot, though: they are completely silent about how modern static type systems might augment or even replace tests. After reading these books, it’s easy to think that “typing” mainly has something to do with keyboards. Read more on More Typing, Less Testing: TDD with Static Types, Part 1…

4 Tips for Improving Test Quality

Test-driven development is an essential discipline for any software craftsman. Similar to how accountants use double-entry bookkeeping as a safety net, software developers can use TDD as their safety net.

If you need a refresher on TDD — and what it is and isn’t — I’d suggest my post on why Simply Writing Tests Is Not Test-Driven Development.

1. Think of Tests as a Sum of 4 Parts

When writing unit tests, it helps to think of them as 4 parts — setup, invocation, assertion, and tear down — and to consider each step as a series of questions. I start with the invocation first. Read more on 4 Tips for Improving Test Quality…

TDD a New Class in NUnit & Visual Studio without Ever Using the Mouse

I’ve been working in Visual Studio a lot lately, and I’ve found a few handy plugins that are very helpful for effective test writing. A good way to show these off is to follow my process for creating a new class and test via Test Driven Development. My goal here is to improve speed by removing the need for using the mouse (not to mention reduce the risk of repetitive strain injuries).

Here’s the short version:

Step Plugin Key press
Navigate to a file in the test project NavigateToTest Ctrl+G
Jump to Solution Explorer Resharper Atl+Shift+L
Create new test file Visual Studio Ctrl+Shift+A
Move class under test to matching folder in core project Resharper Ctrl+R, Ctrl+O
Vertical split between test and class VsVim :vsp
Move files between split tabs Visual Studio Ctrl+W, Ctrl+H/L
Jump between files while editing TabGroupJumper Ctrl+W, H/L
Run the test Resharper Ctrl+U, Ctrl+R

Now let’s take a look at the details. Read more on TDD a New Class in NUnit & Visual Studio without Ever Using the Mouse…

A Beginning Developer’s Experience With TDD

As a summer intern at Atomic Object, I’ve learned a lot about Test-Driven Development (TDD), a practice that Atomic uses heavily. I’d used TDD in one college class, but it wasn’t really explained; we just sort of used it without knowing exactly what was going on.

On my current project, we’ve been using TDD a lot, and learning the process has been difficult. But the more I test code, the more apparent it becomes that TDD is great way to ensure you’re getting the behavior your want from your application.

Why TDD?

TDD helps me understand what my code is doing.

One of the things that I noticed about myself before working at Atomic was that I wasn’t always sure what my code was doing. Using TDD gives me much better insight into how the code works together and enables me to think more clearly about what my code is actually doing.

Read more on A Beginning Developer’s Experience With TDD…

Test Driven Development: Resistance Is… Perplexing?

Recently I’ve been working with a mixed team of developers – contractors from a few companies with varied backgrounds. Our manager is sold on the value of test-driven development (TDD), but most of the team is anything but. The typical reaction to discussion of TDD is highly emotional and highly negative. This resistance is unexpected and perplexing to those of us who use TDD regularly – why wouldn’t you want to leverage a tool that improves your code quality and design, allows you to safely refactor throughout the course of your project, and gives you confidence to make changes late in your development cycle?

At Atomic Object, test-driven development is not optional and its value is not a matter of debate. We’ve seen what it brings to projects over and over, and it’s all too easy for us to spot the quality difference in code bases developed without tests. Would we ditch TDD for a different approach that allowed us to produce higher quality software more economically? Absolutely. Are there cases where we find manual testing to be a better fit than automation? Again, yes. But TDD is one of the best tools we have to efficiently produce reliable, malleable software. It’s central to our process. If you’re not sure that TDD is the way to go, here are a few reasons why you might want to take another look. Read more on Test Driven Development: Resistance Is… Perplexing?…