cwash into software » unit testing

Mocking with JMockit

Chris Wash — Tue, 09 Jun 2009 05:09:58 +0000

Update: I cleaned up the example based on Rogerio’s comments.

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this.

There’s no getting around the fact that some frameworks, especially legacy or proprietary third party modules, are not coded in such a way that it’s easy to write testable code against them. Common pain points include:

Pervasive use of statics
Lack of dependency injection mechanisms
Creating dependencies inline with the “new” keyword

All of these issues will pose problems when trying to double-out dependent code for testing purposes. One approach to solve these problems is to use a dynamic language and metaprogramming constructs to do this kind of doubling. Testing Java code with JRuby or Groovy has become more and more popular for this very reason.

But a lot of these will introduce a level of language abstraction between your test code and the code under test, and you’ll have to have developers maintaining a test suite sign on to learn the language being used.

In comes JMockit, which uses the instrumentation features provided with Java5 to perform a lot of the same magic tricks for you.

This also allows you to test things that weren’t otherwise possible (or are very difficult) and overall I think the programming model is much more in-tune with standard Java programming idioms. It doesn’t discriminate against you if you don’t use dependency injection, but will work with you if you do. Here’s a quick example that colleagues Andy Pemberton and Patrick Cox worked through with me trying out JMockit.

@RunWith(JMockit.class)
public class ControllerTest {

@Mocked
HttpServletRequest mockHttpServletRequest;
@Mocked
ServiceRemote mockServiceRemote;

@Test
public void test_execute_expectations() {

new Expectations() {
{ /* define in static block */
final Model m = new Model();
m.setId(12345l);

mockHttpServletRequest.getParameter("modelId"); returns("12345");
mockServiceRemote.getModel(12345l); returns(m);
mockHttpServletRequest.setAttribute("model", m);
}
};

/* simulate setter injection */
Controller c = new Controller();
c.setHttpServletRequest(mockHttpServletRequest);
c.setServiceRemote(mockServiceRemote);

/* call code under test */
c.execute();

/* strict mode will throw exceptions! */
}
}

You can get the whole project from my GitHub account.

Don’t Unit Test Anymore… No, Really!

Chris Wash — Wed, 18 Feb 2009 01:52:32 +0000

I just read Your Unit Tests Lie to You by Janusz Gorycki and I was going to leave a comment there, but thought it was more appropriate to expand my comments off into their own thing. For those that haven’t read the article, its basic premise is to grab hold of the nearest “test infected” reader and shake the warm and fuzzy out of them. It paints the short sightedness of many recent “unit testing” converts as living in a dream world where unit tests should replace formal testing. It follows with many sentiments I’ve read (and written about here) for a while now. It’s not that I disagree with what is being said in the article, or its tone for that matter; most of what is being said is spot on. Unit testing is definitely not a silver bullet. If you read my blog often, you no doubt get that. The article ends:

So please, don’t fire your QA department just yet. Their job is still important, even if you unit test.

So to Janusz, the fundamental problem here is a general ignorance of the purposes behind a unit test suite. I agree 100% that’s the primary factor behind his problem. What don’t we agree on? Semantics. But semantics are important! How far do we have to go for a true zen-understanding of this issue? Not far. Indulge me —

When is A Unit Test is not a Unit Test?

Here’s my thesis: you may use a unit testing framework, but what you write are developer tests. Even if they are technically unit tests, it is against everyone’s interest to call them this. Picky, useless distinction, you say? Hear me out.

There is a vast difference between the gamut of possible automated tests one could write and what is known colloquially as a unit test. A number of different kinds of automated tests are written against frameworks that are built on top of unit testing frameworks. That doesn’t make them unit tests. It doesn’t make sense to call them unit tests. A square is a rectangle, but does that make every rectangle a square? An automated acceptance or integration test is subject to a completely different set of problems (in areas such as specification, maintenance, complexity) than a unit test. In fact, about the only thing they share is their lifecycle and execution model, which many times has been retrofitted into the JUnit lifecycle and execution model.

“Unit Testing” and Linguistic Drift

I’ve recently seen a number of different incarnations (1, 2, 3) of the argument that we should eschew use of the term “best practice” because of the implications of its linguistic drift and general propensity of people to turn off their brains when just spoon-fed answers, not having to experience deriving the solution for themselves. Similarly, the popularity of unit testing frameworks and the sheer frequency with which the term has been used have, in a sense, set the idea of developer testing back considerably. Cedric Beust makes the point that in many cases we’ve confused [developer] testing terminology with JUnit terminology, and TestNG was in part a response to that. Here we oversimplify the problems we choose to bite-off and the goals we strive toward. They’re not realistic. Is it no wonder so many people fall flat when trying to adopt “unit testing”?

While there may be some overlap with the goals of validation and verification, most in the know consider the true benefits of “unit testing” to be a totally different animal altogether. We seem surprised to find the benefits of doing developer testing have little to do with what “testers” do. This dischord causes a lot of confusion, and has sparked a lot of articles. Some draw this conclusion, appropriately, that developer testing, while it fits a rigid definition of what testing is, shares little with what a typical “tester” is responsible for (true V&V). Quite often developers are the only ones doing any automation work, including this automated “developer” testing. Developers tend to do it for all kinds of different reasons, too. We’ll use a suite of automated tests to proceed without fear of integration errors. That adds value totally independent of validation and verification practices. If our suite catches regressions before we hand a single version off to testers, that saves both developers and testers time. I could go on and on, but the term “unit testing” conveys very little of these kinds of benefits to the development lifecycle, and as it turns out, causes a great deal of confusion.

The Right Usage

When we’re talking pure unit tests, that is, black-box testing components in pure isolation (which requires isolated dependencies), not in concert, as developers we can certainly find merit in this practice. But what we’ve learned is that this idea of unit testing, while quite beneficial as a development practice, shares very few goals with “testing” as we know it from a classical definition of the word (end-to-end V&V). Perhaps a few years ago this distinction was not that true, but we now know better. We know the danger in trying to bend unit tests into something they’re not.

My point is essentially this: knowing how to use a unit testing framework, a very simplistic construct on the surface, to do all of these wonderful things is certainly not something that just “falls out” of developing a unit of code – it’s not something we should expect developers to just deliver each iteration as part of their deliverable like it’s “done.” Effort invested to develop and maintain test code alongside the code under test is not free.

Only if you are persistent will you come to understand there sometimes is very little benefit in terms of “full blown”, classical validation and verification – the whole reason you set out on this crazy “unit testing” kick. You either stick with it, or write it off at this point. If you stick with it, well, I’ll save you the trouble of figuring this out for yourself; you learn it’s only another development practice, that needs to be balanced out with other sound practices. It’s hard work. Really hard.

Then why go to all the trouble? It’s my contention, and I assume most will agree, that developer testing is useful. It drives out better designs, code, and has the potential to thwart a caste of would-be regressions. It can stamp out integration errors. It can help you learn about a new framework or prototype a new feature. But that usefulness comes with a very real cost.

If we truly acknowledge that the type of practice we’ve talked about has merit as a development process, it makes very little sense to continue referring to the practice as “unit testing.” If testing modules of code, driving development with these tests, maintaining them alongside the code, and other automation activities are worthy practice for developers, we should consider the semantics of our vocational vocabulary. Let’s stop confusing each other. We’re not talking about delivering 100% code coverage, we’re not talking about replacing testers (unless you’ve got the huevos to go without them, anyway), and we’re surely not talking about writing or releasing bug-free software. It’s a lot easier to cut through a lot of the hype and confusion if we can all learn to say developer testing and understand it as such. Let’s put the term “unit test” to rest.

R.I.P. unit tests. Long live “developer tests!”

In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel

Chris Wash — Sun, 01 Feb 2009 01:16:05 +0000

Update: Robert Martin is scheduled to appear on the Feb 10 episode of the SO Podcast. Should be interesting to see where things go. Also, Jay Fields has weighed in on the topic.

Update #2: Listened to the new SO podcast and am working on a short followup post. I just met another local boy and kindred spirit in Justin Etheredge who has also had a few things to say about this whole debacle.

I wanted to add my two cents to this philosophical, in my view very important, but not very pragmatic debate. For the uninitiated, the argument begins with the Stackoverflow Podcast Episode #38 which is a discussion between Joel Spolsky and Jeff Atwood. They discussed, among many other topics, some of “UncleBob” Martin’s recent material found in his book Clean Code, (actually, Spolsky cited Martin’s appearance on Hanselminutes as the spark to his comments), which Martin responded to with a number of tweets and a blog post.

Jared Richardson introduced me to the idea of technical debt, (term was coined, like so many other terms, by Ward Cunningham) which I think is a pragmatic way to cut through the philosophical differences in this argument. But in the interest of carrying on the debate, and because it’s the weekend, I’ve decided to (perhaps) add some fuel to the fire. Please don’t read this at work.

The gist of the argument is about how much emphasis you should focus on robustness/code hygiene/maintainability in your code, even if it is unclear there is much business value in doing so. Essentially, if we consider impacts to budgets, deadlines, etc., and even in terms of its impact to your code (see Antipattern: “Yet Another Useless Layer”) — is it worth it? It’s very much a discussion of what software quality is and why is it important, which raises questions like:

Are robustness and business value mutually exclusive?
Does quality require rigor and conceptual cleanliness?
Is code hygiene a purely academic pursuit, or is there intrinsic value in it?

These are interesting questions. Atwood and Spolsky take what they feel is a more pragmatic position; Atwood explaining quality in terms of a Frank Zappa quote [paraphrasing] “Nobody gives a crap if we’re great musicians,” meaning that what matters is ultimately what is delivered to the customer. He explains further that “Quality is just another axis” — another set of competing concerns for your development time and interest. Spolsky’s comments constitute a self-professed rant that there is a thread of zealotry in the OO community around TDD. It reminded me a lot of what Cedric Beust has argued in reference to what Jim Coplien has debated with Martin himself. While Spolksy could be playing devil’s advocate, or could have been looking to start a “blog fight” (already popping up in comment threads) I think he could have gone about it in a more pragmatic way. While Beust does paint Martin as a zealot as well, at least his main point didn’t portray unit testing as just short of completely useless; rather, he is one of the creators of the popular TestNG framework:

“Tests first” or “tests last” is unimportant as long as there are tests.

I might be wrong, but I even remember reading a section of Clean Code in Borders last week and essentially reading Beust’s point in Martin’s book. It stuck out in my mind after watching his debate with Coplian. But I digress.

Before going further, I wanted to point out how much this debate reminds me of From pirate dwarves to ninja elves…, which I believe is a great way to classify personality types — especially those of people writing code. We know for sure that UncleBob falls into the Ninja-Elf quadrant. He thinks practicing TDD is a professional responsibilty and lays out his own definition for TDD in Clean Code. I think this is the very definition of a Ninja-Elf. My personal leanings are toward that quadrant as well. When you are innundated with Dijsktra, the ulitmate Ninja-Elf, in school, the following quote really sticks with you:

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself “Dijkstra would not have liked this”, well, that would be enough immortality for me.

But there are people whose opinions I respect with Dwarf-Pirate leanings, too. Obviously Atwood and Spolsky lean in this direction (though they may not fall directly into that quadrant). I’ve heard some others that I respect espouse the same opinion as Spolsky; Gavin King, for example, I’ve heard him say, “The types of bugs that I introduce usually aren’t caught by a unit test.” He wasn’t as over the top in his argument, he simply explained that he prefers integration tests. And I don’t think you’d hear any of the people mentioned in this post say that they never write any tests. For a great argument from the ultimate Pirate-Dwarf see Cal Henderson’s normalized data is for sissies (slide #27); it is pretty entertaining and compelling when scalability is of utmost concern.

I think Atwood’s argument ultimately came down to championing the idea of continuous production; that being able to respond to change or bugs found and having a quick no-brainer deployment process is the Zen-like state you’d like to get to. But the idea of getting there is that it comes out of some notion of continuous integration, which is predicated on the idea of testing. Henderson himself makes this very argument (I believe in this talk, but perhaps in another). You need to trust your team enough to get changes and fixes out to address problems quickly, and be smart about what you spend time on. Testing is great and if you can find people that can test their code well and be productive, that’s awesome. But Henderson’s point is those people are extremely hard to find and retain.

All this goes back to the old question, is producing code an artistic or engineering practice? (Interesting that Atwood supported his comment with a Frank Zappa quote about art.) Obviously you need a talented and cohesive team to be able to make it work either way. I think the answer is it has to be a little bit of both. You’ll need some measure of creativity, some degree of engineering aptitude, also strong analytical skills, and to succeed in a business environment, some acumen in decision making and managing (at the very least your own time).

The fact is, though, that we’ve come leaps and bounds in terms of being able to efficiently produce these tests, and balance their production and maintenance out with constraints, business expectations, budgets and deadlines. And it can fuel your creative side, too.

As for professional responsibilities, I definitely wouldn’t recommend trying to write code without at least some tests if you expect anyone else to have to maintain your code. If you’ve got a close knit team and an overwhelmingly urgent need to deliver untested code (and are of the Pirate-Dwarf persuasion) then go for it. But that being said, I’d say I agree with Martin and Jared Richardson that argue it’s a professional responsibility to not take on the technical debt of untested code. Of course, if tests mean you can get maintainability (and other -ilities) along the way then I think that you’re well on your way to a quality product.

One final way to look at this: would you say it’s better for your team to take the view that code is innocent until proven guilty, or guilty until proven innocent? In the interest of skepticism, considering the teams that most developers “in the trenches” have to work on, and how far we’ve come in making testing easier and more efficient, I’d need a very strong team to make the assumption that all they code they write is innocent. We all make mistakes. I believe this is also brought up in Clean Code.

Ultimately the message Atwood and Spolsky send in their Stackoverflow podcast is that unit testing and efforts to support it are not a silver bullet. Personal slights aside (“I don’t think these people write very much code.”) they have a point — and Martin agrees in his blog post. But I think it took them a long time to make that point which is certainly no great revelation. In the end, I did not feel they explained a whole lot about what the right approach to quality is, but communicated their distaste for an attempt (especially if accepted dogmatically) that aims to do so. I can relate to this, and agree you must treat what you read, hear and are taught with a healthy dose of skepticism. Martin’s ideas may seem dogmatic on the surface but I don’t think it’s fair to paint him in that light. If you really read what he writes, I think he realizes that he is a voice many people are listening to, and works hard to say what he thinks is the right. Martin defends a style of development that favors more rigor and discipline than many others feel is necessary, but in an industry that can be categorized by its lack of discipline, I can’t do much but respect him for that.

Must Haves/References For Modern Java EE Developers

Chris Wash — Sat, 29 Nov 2008 01:10:54 +0000

I’ve been doing a lot of reading lately and have been meaning to plug some of my favorite reads, and one of the things that I’ve been trying to read with an eye toward is for converting those that have been stuck on “behind-the-curve” projects to the new way of thinking and doing things. As such, and just in time for the weekend, I’ve compiled a list of my favorites with an eye to the “movers and shakers” that have driven innovation in the Enterprise Java world recently. Note that even though some of these links are specific to certain frameworks/technologies, there is a common thread throughout most of these that have a bigger focus on the best way to solve problems using Java 5/EE 5 constructs and concepts.

A book that should be on any Java developer’s shelf is Effective Java (2nd Edition). Make sure you get the second edition, for all of the Java 5 changes. This talk by Joshua should whet your appetite. (His talk on good API design is also very good.) You should also take a look at Bob Lee’s talk on Guice. Guice’s philosophy and focus on typesafety has spilled over into Web Beans (and newer versions of Seam) and its annotation based approach has heavily influenced newer Spring features. I especially like his points on type safety around the 11-minute mark. The walkthrough at the end of the talk from “old way” to “new way” is great for people who haven’t really gotten away from Factories, Delegates, and Service Locators yet.

The Guice video mentions that a common thread in modern Java frameworks is a focus on testability. Testing is a very important concept that nearly all new frameworks have embraced, but you still need know-how to be successful with testing. I’ve come across some great books recently in the automated (developer) testing arena. I’ve found the most thorough book on the topic out there is Lasse Koskela’s Test Driven. The ideas and topics discussed in the book are really language independent, and work equally well with other languages. To cut your teeth on TestNG, which the Seam documentation turned me onto, I recommend the TestNG developers’ book Next Generation Java Testing: TestNG and Advanced Concepts. Cedric Beust, also the author of EJBGen, and Hani Suleiman, author of the Bile Blog, produced a book that was a suprisingly good read. It’s packed with a lot of knowledge and some interesting takes on EE concepts. Newer versions of JUnit also include many of these features and concepts, so you’ll get the underpinnings of these concepts in this book. This video gives you a basis to TestNG’s approach.

As one of the growing number of developers who have an application in the Seam In Production page, there are a few Seam resources I have to share. Even if you don’t get into Seam, it should be on your radar because a lot of the core concepts around conversations have evolved into Web Beans, and are found other frameworks like Apache Orchestra and Spring WebFlow. Pete Muir did a Webcast that’s a great introduction to Seam 2.

Author of one of my favorite Seam blogs, Jacob Orshalick, has created a DZone RefCard for Seam 2.1 Core. It’s right off the presses, being published this week, but is a great quick-capsule review of what Seam can do for you, and nice to have on your desk if you’re writing Seam. If you need more in-depth descriptions of what’s on the RefCard, Jacob also coauthored the latest edition of the great Seam reference Seam Framework: Experience the Evolution of Java EE.
Dan Allen’s Seam in Action is another excellent resource. Of course, the awesome Seam Docs and Forums always come in handy. You should also RSS in.relation.to – the Hibernate/Seam developers’ group blog.

I know I’m leaving some great things out. What resources do you think someone who is used to J2EE should take a look at to get them “up to speed” with the state of the art?

Continuous Integration Dissected

Chris Wash — Thu, 13 Mar 2008 16:29:06 +0000

Setting the Record Straight

A lot gets written about Continuous Integration, particularly on which is the best visual cue to let you know your build is broken or that a test is failing – lava lamps, Beta Brights, Ambient Orbs, and some even suggest traffic lights. But aside from this extraneous (at least to business) nerd-banter, a lot of what I find written about the actual topic of CI is fluffy, ivory tower, or pie-in-the-sky jibber-jabber that leaves out important parts of the big picture or confuses people more than it helps. In hopes of clearing up confusion on what exactly CI is and how it’s supposed to work, I’m ripping out a description that I wrote for a client proposal recently (so my apologizes for the dry-tone). I hope sheds some light on the true nature of CI, why it’s important and how to implement it from a birds-eye point of view.

Continuous Integration Dissected

Any large scale development project needs an automated, repeatable build process. Following best practices while developing a build process properly separates environment-specific configuration concerns from the codebase. This allows new environments to be created quickly and easily by simply overriding any environment-specific configuration values when first executing the build process. Whatever build tool is being used, builds should share a common, consistent process and interface. A consistent, repeatable build will know all of its dependencies and the goal is to be able to build any given module anywhere, independently, at any time.

Automated, repeatable build processes typically begin by obtaining dependencies (which can be specified using a dependency management tool) and a specific working-copy of the codebase (“checking out”) from a SCM system like CVS or Subversion. It is important to note that this codebase includes any code that is responsible for performing automated testing in addition to source code and configuration (and possibly other source-like artifacts).

Once the checkout has completed, the process will compile code and run automated unit test suites for each module in the system. At this point, all automated unit tests should pass, and custom development can begin. Any changes to code must be adequately covered by unit tests (either by changing existing tests or creating new ones), must fully compile without any errors and pass all automated unit test suites before being committed to the repository. The practice of always keeping the code committed to the SCM repository in this state (no compilation or unit test errors) is known as Continuous Integration and ensures that new development is safe to proceed at any point without fear of integration errors.

Subversion (and CVS) support concurrent development by following a Copy-Edit-Merge paradigm; any contention over files is usually caught when a developer tries to commit their changes and notices the underlying files have changed since they obtained their copy. In many cases, Subversion is capable of performing a merge automatically, if there was no contention over the same piece of a file. Sometimes, however, a manual merge will be required. Merging becomes more painful as the number of differences in the conflicting files increase. A good rule of thumb is that every developer should commit their changes at least daily.

Designating a single machine as a Continuous Integration (CI) environment provides many added benefits to a large scale development project. There are many operations which are good candidates to have run “continuously” but quite often are too expensive for developers to perform before every commit. Examples include executing automated in-browser system tests (which, if maintained over multiple releases, can serve as a “mini” regression test suite), performance tests/profiling, producing test metrics, generating documentation, etc. CI servers are an ideal place to schedule these processes to occur in an automated fashion.

Bugs, Detectives, and Test Automation

Chris Wash — Tue, 11 Mar 2008 21:08:33 +0000

You’ve done a thorough code review with your team and your code has come out with a few nice improvements. Good. You know that many a trustworthy source have speculated code reviews find as many as two times the number of defects that testing does. So you might suppose going to the trouble of creating automated tests, simply for your own devices, might be a bit overkill. As it turns out, it is worth it, and it’s going to save you a lot of time in the long run. Why is it so valuable?

Indulge me in a brief aside… I saw Full Metal Jacket recently on cable for the up-teenth time; the first act of the film, the part that is set on Paris Island, is hard for me to flip away from. I usually end up catching at least the first quarter of the movie. If you’ve seen it, you’ll probably remember the part where the main characters recite, as new recruits, the Marine Corps prayer – it ends with “Without me, my rifle is useless; without my rifle, I am useless.” I think the prayer metaphorically makes sense if developers were reciting it and replaced the rifles with their automated tests.

To figure out why, let’s answer the burning questions that first come to mind:

Why should a developer care about doing their own testing?

It alerts you of problems (duh).
You’ll have a check in place in case a bug ever comes back to life.
It gives you the opportunity to fix things before anyone else finds out about them.
It’s the best way to demonstrate that your code meets its requirements!

Why don’t you want testers (or worse, end users) to find your bugs?

First of all, let’s be honest, this is an ideal to strive toward, even though actually achieving 100% test coverage and catching every possible bug is a definite pipe-dream. But we have to keep in mind that bugs discovered by people other than a developer cause a lot of speculation, confusion, and in general, overhead work for everyone – time that could be better spent doing more productive things. We’d like nothing better than to hand testers (and ultimately users) squeaky-clean code. What happens if we don’t? (and you won’t!)

Imagine taking a class of third graders outside to find an insect in the “wild” and learn about (not burn) it with a magnifying glass. You’re even able to get everyone to concentrate long enough to take a peek at a would-be critter. The first candidate you find turns out to be a piece of bark that looks like a beetle. As you’re searching for another, two of your students get in a fight over claim to a partially decomposed boot they find. Another gets a nose bleed. When you finally manage to find another potential insect, you pass it over, mistaking the critter for a leaf. Little do you know it is actually a very well camouflaged member of the family Phyllidae. By this time a child has fallen face first into a mud puddle and another has peed in his pants (which, one would think, should start to attract some insects).

Imagine that you do manage to find an insect in the wild; how would you get the whole class to observe it properly? There’s just one magnifying glass. The moment you get it under the glass, it darts away. It’s a struggle to keep track of. Not everyone is going to have a good viewing angle. If it disappears, then it might just as well be dead to you (did you hear that tree fall in the woods?).

Enough already with the horrible analogy? Okay, okay. The comparison of users to third graders in our thought experiment was purely coincidental – but you get the point. Having a group of people focus on a moving bug in “the wild” is tough! It’d be much easier to bring a captured critter into a controlled class environment to observe – our analog of a bug that we have caught with nifty our automated test net.

Bug Detective?

Given the fact that a tester’s job is to find defects, odds are sometimes you’ll get a defect report filed that looks like it’s written in cuneiform and requires a wizard’s hat, cauldron and lizard eyeballs to reproduce it. Sometimes a tester might not be giving you a legit bug – sometimes. There are a few scenarios that come to mind:

A requirement is incomplete, misunderstood, miscommunicated or changed.
An external system was down.
An admin fat fingered something.

This comes with the territory and you’re just going to have to suck it up. You’re ultimately the gumshoe on the case. A good way to think of it is that testers and users are like the police of our system – they’re responsible for being the first on the scene, drawing chalk outlines, “booking” the suspects we arrest, etc. What the tester is explaining is probably going to confuse you at least a few times before it makes sense. If you have good testing support, this might not be that painful. But you could have the Super Troopers on the case, and each clue that comes in is going to waste more and more of your time. And heaven forbid an end user finds this problem, and then tries to communicate this to a support rep – your job then becomes ten times harder because you have to decode 2-3 levels of miscommunication that’s occurred. Sometimes no good comes of all this, sometimes you find and squash a bug. In cases where you don’t know what to do, write some tests – ask what the outcome should be, let the answers create more questions and more tests. And be sure to hold onto them!

Whatever the outcome, because good developers are lazy, we want more than anything else to prevent this from ever happening again. Worse case, you’ve spent a lot of time addressing something and should have at least a documented set of work you’ve done and decisions made. Make sure others know about this. Best case, you are able to add an automated test so you don’t have to think about this ever again (or tell anyone about it – you’ll know the moment when something goes wrong).

Conclusion

So let’s recap –

Bugs that slip to production are costly!
Automated tests help us exercise code before and after it goes into production.
If we work on a defect, our automated test net can help us catch a bug, or examine something that looks like a bug more closely.
Whenever we work on a bug (even if it’s something that isn’t truly a bug, but is being tracked as one) we should do our best to produce an automated test so we don’t have to reinvestigate in the future. A test beats an email- or source control commit-trail any day!

cwash into software » unit testing

Mocking with JMockit

More Related Content

Don’t Unit Test Anymore… No, Really!

When is A Unit Test is not a Unit Test?

“Unit Testing” and Linguistic Drift

The Right Usage

More Related Content

In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel

More Related Content

Must Haves/References For Modern Java EE Developers

More Related Content

Continuous Integration Dissected

Setting the Record Straight

Continuous Integration Dissected

More Related Content

Bugs, Detectives, and Test Automation

Why should a developer care about doing their own testing?

Why don’t you want testers (or worse, end users) to find your bugs?

Bug Detective?

Conclusion

More Related Content