A test guy

apropos of nothing, some stream of consciousness thoughts while scanning twitter. (hey look, I’m blogging again!)

• I like to know what I am doing, and why I am doing it. (mindfulness)
• I like to know what we are doing, and why we are doing it.
• I like to know what we did, and why we did it.
• I like feedback. Fast feedback, and close feedback.
• I like creating affordances.
• I like precision and accuracy.
• I like to tell my audience when I am compromising precision or accuracy in order to better reach another goal.
• I like people who are hungry to learn. (they make me a better teacher)
• I like french vanilla ice cream.

Over the past few weeks, I’ve been working through the book Agile Java – Crafting Code with Test Driven Development, by Jeff Langr. Why?

• I’m evaluating it as a self-study guide for a co-worker who wants to learn java.
• While I’ve read plenty of java, and made small modifications to existing java programs, I’ve never written a major java program from scratch, nor have I ever set out to systematically learn java. So I’m learning java. yay!
• While I’ve written plenty of tests, and I’ve modified some existing tests, and I’ve written tests before I’ve written code, I’ve never written a major program using xunit-style tests and doing TDD. So I’m learning TDD. yay!
• I’m also taking the opportunity to immerse myself in eclipse and intellij

I’ve had some interesting experiences (thoughts and feelings) doing this, and I’ll write up some details in separate posts.

I just finished lesson 12. Earlier, I wrote the following in my notes:

I’ve gotten through the end of lesson 6, and I’m very impressed. I feel confident that I can recommend this book to my coworker, and he’ll be better off going through it than not.

I’ve been using eclipse more than intellij for lessons 5 and 6, and I’m steadily becomeing more comfortable with it.

I found and installed the EclEmma plug-in, and very much like using code coverage to identify code I can delete after some refactoring. And I’m duly impressed that I get 100% code coverage when I run my tests*

*actually, almost 100%. the gaps are things like assertTrue not being called with a false condition (duh), never calling the constructor of a utility class, and not testing the default methods for enums. I can live with that, for now.

One thing I did not expect was that my brain felt like it filled up and overflowed, and I kept forgetting what I was doing, as I got towards the end of the lesson 6 exercises.

more on that last bit soon.

(if it is wrong, consider me tragically misinformed)

In the Navy, when they have a “bad ship”, they disperse all of the crew throughout the fleet, then assemble a completely new crew and try again.

Applying this lesson in our context – if you have a “bad team”, break it up and assign the team members to other teams. Then staff the project with a new team and try again.

Just like breaking up a great team and assigning the members to other teams won’t necessarily turn those other teams into great teams, doing so with a bad team won’t necessarily turn the other teams into bad teams.

This lesson is not license to turn your brain off. Bad team != bad people, and sometimes there are people who would find a better fit at some other company or pursuing some other career.

In most software development groups I’ve worked, there have been at least one or two programmers who both believe in unit testing and have the discipline and knowledge to create good unit tests. This has not changed during my career.

I’ve seen a few groups where there are enough unit-test-infected programmers to create critical mass, and the entire group writes, maintains, and believes in unit tests.

I have seen even fewer companies that explicitly and consciously set out to build a group of programmers with the above critical mass in test-infectedness.

So I wonder if the majority of companies where good unit testing happens are the result of chance.

(in response to questions about Is unit testing doomed )