Skip to main content

88 posts tagged with "programming"

View All Tags

Review: Growing Object-Oriented Software, Guided By Tests

· 3 min read

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce

I did not realize how much I still have to learn about writing good object-oriented (OO) code, and about hewing to a tight test driven development (TDD) methodology, before I read Growing Object-Oriented Software, Guided By Tests. My education in OO and unit testing has been largely theoretical, with no time spent directly learning from experienced OO programmers; my best mentor was a COBOL coder. Books like Design Patterns: Elements of Reusable Object-Oriented Software ("Gang of Four"), Patterns of Enterprise Application Architecture, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Xunit Test Patterns: Refactoring Test Code, and others are wonderful but have few detailed real-world business-case examples.

Moles: No Longer Fit for Unit Tests

· 3 min read

No moles

Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!

The first clue that I might need to walk away from Moles was the recent difficulty another developer was having in trying to get a unit test project up-and-running on his computer. I had installed what was current in early 2011, and he had installed the current version from last 2011. Turns out there was a significant change – the config file no longer worked. We had to update the assemblies correctly on my machine, rebuild many times, and fool around with manually removing some assemblies. It got confusing and messy. I suppose that's why MS still labeled this version as < 1.0.

Test Naming Convention

· 3 min read

Historically I've advocated naming test methods after the method under test, in order to help find the tests when you need to modify them. Growing Object-Oriented Software, Guided by Tests has shown me that this is a relic of a code-first mentality rather than good application of test driven development, primarily in the section "Test Names Describe Features" (ch 21). "Test driven" development implies that we do not know the name of the method we're going to test. But we do know the functionality (feature) that we are going after, and that knowledge should be used when writing out a test name. For example:

Mythical Man-Month: Planning for Change

· 3 min read
info

Part four in a series about Dr. Frederick Brooks Jr.'s The Mythical Man-Month:

1, 2, 3, 4 (this piece), 5

In the chapter titled "Plan the System for Change," Dr. Brooks again lays out the foundations for Agile software development. His was an era of dumb-terminals and highly scheduled availability. And yet, here he is saying, "plan to throw one away; you will, anyhow." When RAM wasn't cheap, and good programmers even more rare than today, how does a project manager or architect justify throwing out the first design on purpose? By recognizing that "[t]he only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers."

safnet logo