As a manager, I want to tell a team what I need and they make it. Is that too much to ask? It depends what you mean by “tell.” Without the information we need, work is like “Bring me a stone.” In this game, the Boss says to the Worker, “Bring me a stone.” The …
In software and in life, breaking tasks into the tiniest possible pieces makes them smoother, and therefore easier and safer.
These days I work on Rug, Atomist’s library for coding code modifications. Adding a feature, I start by creating a test. While it’s tempting to create a narrow test around the piece of code I want to change, it’s better to create an API-level test. Testing at the outside has a few benefits: it tells …
Say I’m in retail, and the marketing team has an app that helps them evaluate the sales of various items. I’m working on a web service that, given an item, tells them how many purchases were influenced by various advertising channels: the mobile app, web ads, and spam email. The service will look up item …
Imagine that you’re writing a web service. It is implemented with a bunch of classes. Pretend this circle represents your service, and the shapes inside it are classes. The way I learned test-driven development[1], we wrote itty-bitty tests around every itty-bitty method in each class. Then maybe a few acceptance tests around the outside. This …
Today in Unit Testing, an evil framework class hid my important return value away in a private field. Groovy to the rescue! So far, all our code and tests are in Java. It took only two lines in build.gradle, as specified in the gradle documentation, and poof. I put my little test class in src/test/groovy/package/structure, …