Eunuch Test Antipattern

I ran across a horrible anti-pattern today — JUnit test class methods called “doNotTest…” I think I’ll call them Eunuch tests. It’s pretty clear that either a) the team is not doing TDD because they can’t figure out how to test the code they already wrote or b) some “refactoring” wasn’t a refactoring but instead a code word for “dangerous unknown swath of changes to code”.

I don’t know whether to laugh or cry, but it’s Friday, so I choose to laugh today.

potential differences [/testing] permalink

Educational Tests

Brian Marrick comments on Mike Clark’s blog entry Staying Fit With Learning Tests . I’m quite interested since I noticed some of my own backsliding behavior recently when I was writing code against a new API. I was writing my first JMX MBean, and had no one experienced with JMX around for guidance. I didn’t write it test first :-O

I did, however, go back and give it a full unit test suite after-the-fact, and it has been rock solid in production. It did take some refactoring to get it in shape to be easy to unit test, so the late testing step did improve the design. Anyway, back on topic: I attributed my backsliding to the fact that I was exploring/learning a new API.

I think there’s a well-known compromise between Brian and Mike’s approaches, and I’m waiting for a Smalltalker to go into more details — the Inspector. My first development job was for the Apple Newton PDA, which used a custom language called NewtonScript that had features from a number of languages (I’ll try really hard not to bore everyone with all the details, but suffice it to say that it was really a great language to program in, but I was too inexperienced to really realize it at the time).

One of the features the NewtonScript IDE copied from Smalltalk was the Inspector. I’m sure I never used it to its full potential due to being young and dumb at the time, but it allowed the sort of interactive exploration Brian is mentioning, and stored these “lessons learned” in a file that could easily be reopened and re-executed at any time. Mike’s learning tests don’t sound like they’re going to be included in the regular source tree and build process. The only reason they would be saved is to review the lesson and copy/paste some of it into the real system.

Eclipse has the concept of scrapbook pages, which are essentially renamed Inspector pages. It’s not too surprising considering Eclipse’s Visual Age roots, however, I was coding in IntelliJ IDEA so I didn’t think of a scrapbook until I read Brian’s blog. The advantage of an inspector/scrapbook page over Mike’s practice is that you don’t need the overhead of a full compilation unit. You don’t have to have a class and method in which to place executable lines of code. The ‘run’ function of the scrapbook handles that for you.

I suppose I need to explore some more nooks and crannies of IntelliJ to see if scrapbooks are available, but I had looked briefly when I first switched from Eclipse and did not find them. Perhaps it is time to file a feature request.

potential differences [/testing] permalink

Developing and Testing Mindsets

Mike Clark writes about tearing down the barriers between testers and developers. I’m all for that, but I’m not convinced that abolishing the terms “QA” and “tester” is the right approach.

At my current job, one of the resons I was hired was to get a test driven mindset into the development community. One of the things I had to do was to make sure that the testers did not feel threatened by this push. I’ve gotten to know the testers and have begun reading articles and blogs from testers. I believe there are important differences in the skills and mindsets of good testers and developers, and I want to mine that before the distinctions of the titles are taken into question.

Test Driven Development is primarily a design tool, and secondarily a verification tool — and even as a verification tool it is woefully incomplete. It focuses only on the small scale. Testers focus on the verification angle — the design is secondary to their task. They’re looking mostly at a functional or system level of granularity, and this is much closer to the level the users are going to judge the quality of the software from.

Our lead tester told me the other day that she comes from a programming background, but ssshhh…. don’t tell anyone because she hates doing it. I replied that I don’t have the tolerance of detail that she has and would hate being a tester, but that I have great respect for the job they do. I still don’t have a complete picture in my mind if what the fundamental difference is. Programming certainly requires attention to detail, but it is different somehow. I’m going to be exploring this more in upcoming blog entries and try to understand what and how we can learn from each other to further our common goal of better software.

potential differences [/testing] permalink