Agile Otter Blog

Today I was thinking about the phrase "under test" as in "we've got to get this code under test so we can fix it." I started of thinking about the way the app we were discussing was laid out. There was (at rock bottom) some persistence stuff. Above that was (on one side) reporting and query, and on the other was some business objects. Above the business objects are some model-like objects (sometimes) and above those are UI-related code. Starting at the "top", with UI presentation, we can test through a browser. That makes it the territory of human by-hand testing and also of browser emulators, browser drivers, and screen-scrapers. Such tests are going to exercise a fully-integrated system, and can be slow due to many features such as database access, file system access, network access to services, etc. Human testing is particularly slow, as it involves reading time, typing time, and time to evaluate results. Human tests we can measure in minu...

We tackled some code for refactoring, and I found an unusual construct. To wit: public class Base: Many, Varied, Bases { private int x; // ... public class Derived: Base { public setX(int value) { x = value; } } // ... } So here we have the derived class nested in its base class. I am quite comfortable with nested anythings in python or a few other languages, so that's not a problem. I nest 'testable' classes in tests all the time so I can override or stub a few methods. In python it's a normal way of life to nest functions and classes. This one is odd because it is a production class, nested inside a production class, and deriving from its outer class. It makes me think of a pregnant female, having a child inside it whose dna derives from the mother. So what powers does this odd nesting convey? My first thought is that it is some kind of closure, but this turns out to be false. There is no real closure ...

I recently collected up some information from Jira and git about our software process. I am mulling over an idea, and a little feedback is welcome. To help understand the context, among our products we have one codebase that was originally written pre-agile in a non-TDDed manner but greatly improved during and after the company's agile transition. It is pretty good stuff, and constantly improving in quality and functionality, consistently delivering real value to customers. We're pretty of proud of it and its future. There is a great team working on it. Sometimes, though, we find the need for a large-scale refactoring somewhere in the code base, and we have the courage to tackle these. Basically the problem is that refactoring sounds bad to product managers. When it's done well, there is no visible difference in the code. When it isn't done perfectly, it injects defects. The obvious knee-jerk reaction is to resist any large-scale refactoring efforts. As an a...

I had some fun recently after agonizing over the problem of bug prevention.  I put out the observation that bugs have a tendency to cluster, and that the more often code is edited the greater the need for the code to be frightfully virtuous , clean , and thoroughly tested . The problem was with determining which code should be cleaned up in order to reduce the injection of bugs. I considered various metrics and measurements, including cyclomatic complexity, code duplication, and various design details, but ultimately dismissed them for fear that they would be unconvincing. I didn't want my audience to think the heat maps is just "coach Tim lecturing."  In keeping with our description of effective information radiators we needed the information to be simple and stark. Our SCM is based on git, and our tracking software is Jira. We have to include a recognizable, open, Jira ticket id in every code commit. Many of the tickets are enhancements, improvements, or investig...

I write an automated acceptance test (AT) and I find that I would like to perform certain actions against the business objects.  I create a method on the business objects and my test stays slim while my model builds up more functions. So, there is potentially code in the production system that is only used in the tests. The debate today is whether that is "unnecessary bulk that solves no business need" or is instead "first-class code." I am betting that the code you need in the AT is code you probably also needed in the UI and/or APIs to external clients. I am supposing that it is needed in the test because it is likely written into the UIs instead of the model and so the tests' logic is duplication. I also think that even a reasonably poorly-written test is written to support business rules.  Therefore, the tests express business logic so methods required by the tests are methods required by business.  While some worry that a method on a busin...

We had a nice talk today about the natural foot-dragging that is common among pair programmers when it comes time to switch partners. It's not really social, as in partners gravitating to each other as buddies. Instead it tends to be more work-related.  It does feel socially awkward to tell your partner you want to go work with someone else now. It sometimes does happen that partners who are gung-ho agilists will prefer working together. They prefer partners who allow them to do their work well and will improve them over those who create drag by arguing against testing or refactoring. People get comfortable in a particular task and want to see it through.  This is a good feature usually, and certainly is favorable for people who do individual, non-paired work. In an agile team, it's limiting. Someone needs to move on so that there are more eyes/hands/minds in the code. If there is no standup there is no pair switching.  If the team relies on assignment from a manage...

I've been developing new skills, and working with Jeff on the AgileInAFlash project . What's new? Our latest article for Pragmatic Programmers.