The Code Whisperer

I wish that I could take credit for this article, but I can’t.

[We might choose to] write tests so that a failure in a predecessor test causes dependent tests not to execute.

The 30-second version Where did that yak come from?

The 30-second version Invert the dependency on a Service, moving the new statement up one level in the call stack.1 Repeat for all dependencies on Services until the corresponding new statements arrive at your application’s entry point.

After running a handful of Legacy Code Retreats I’ve had the chance to try a number of exercises related to rescuing legacy code.

One of the people who watched the 2009 version of Beware the Integrated Tests Scam (was Integrated Tests Are a Scam) recently asked me: I wonder how you deal with updates of third-party libraries.

As I learn to become a better programmer, I continue to follow the four elements of simple design.

I just wanted to know whether anyone has tried nesting the concrete tests inside the abstract test like this, and if you have, then how do/did you like it?

I found an example of contract tests in Arlo Belshee’s series of articles about mock-free testing.

The 30-second version Adding behavior confidently involves having fewer parts to change (low duplication), knowing which ones to change (high cohesion), ease of changing just the part you want to change (low coupling), and understanding how you’ve changed…

A Model for Improving Names A model for improving the names of variables, fields, interfaces, classes and namespaces in a system.

I found someone trying to work on improving names in their code, and gave them a little advice.

We’ve read this before: don’t reuse code by subclassing.

I’ve taken this verbatim from a thread in the Google group for Steve Freeman and Nat Pryce’s excellent work, Growing Object-Oriented Systems Guided by Tests.

I recently received this comment at IBM DeveloperWorks about my now-very-old article, Use your singletons wisely.

I have noticed a recent swell of comments about the pain of dependency injection, and if this has caused you problems on your project, then I think I can help you by offering a few simple guidelines and a single goal for injecting dependencies.

Although I originally wrote this to describe how/when I use JMock compared to Mockito, you can easily read this as an article comparing the use of mocks (expectations) to the use of spies.

I came across this question on the testdrivendevelopment Yahoo!

I recently read this article at mockobjects.com and it reminded me of advice I give when I teach people about test doubles.

One of my faithful readers at https://www.jbrains.ca told me that he couldn’t find an RSS feed icon in his Firefox address bar.

I made this announcement at a TDD course in Bucuresti this week, and I wanted to make it here: I now fully and freely admit that when I use the term “integration tests” I confuse people unnecessarily, and so I will stop.

I wrote this article long enough ago that it refers to “integration tests”, when I really meant “integrated tests”.

I wrote this article long enough ago that it refers to “integration tests”, when I really meant “integrated tests”.

I just finished reading Brian Marick’s article, “Mocks, the removal of test detail, and dynamically-typed languages”, which focused me on a design technique I use heavily: awareness of irrelevant details in tests.

The 30-second version I can find integration problems of basic correctness without integrated tests using a simple double-entry book-keeping approach.

I tried to respond to a comment from James Bach, but surpassed the 3000-character limit, so I’ve decided to add this long comment as a short article.

I just read a tweet from Dale Emery that turned my attention back to the topic of integration tests and their scamminess.

I fear that this first article in the series may be attacking a view that very few people hold: the idea that one should test all code paths by integration testing alone. — Dan Fabulich When I tell TDD practitioners my opinion about integrated tests, some…

UPDATE.

Contract Tests explain how a class should extend a superclass or implement an interface, so that I don’t have to read a bunch of prose to figure out how to do that.

I originally wrote this article in 2003, based on experiences I had from 1997-2001 while working at IBM.

Not long after the Christmas break between 2001 and 2002 I wrote “JUnit: A Starter Guide” in response to a flurry of complaints over the lack of a decent JUnit tutorial.