Perryn Fowler writes: "Can we make the computer generate the implementation that makes the tests pass? Maybe. I can imagine for example something that took a Junit or perhaps even a FIT test and generated code to make it pass. I don’t imagine it would be easy, but I imagine it would be possible."
link
Steve Freeman writes: "NUnit is progressing with version 2.2 in beta. It’s coming along nicely, but eventually I’d like to see them use the Constraint concept from the dynamic mock libraries, instead of simple equality."
link
Joe Walnes writes: "I try to avoid using code that instantiates threads from unit-tests. They’re awkward to write, brittle and I would rather extract the controlling thread, using the test as the controller. However there are times when it’s unavoidable."
link
Julian Bucknall writes: "A reader asked me a few questions about Test-Driven Development (TDD) and I thought them interesting enough that I decided to mold them and my answers into a blog article."
link
Nathan Lee writes: "The trouble I see is that there is an emphasis (generally) on testing [..] the functionality on DEV, QA, but then you’re generally not going to be running tests through a production machine… so how do you check for configuration changes?"
link
Charles Miller discusses the two main uses of mock objects (set up a fake environment & test what changes the object being tested makes to that environment): "I’m resuming my battle against mock objects today. It’s not that I have anything against mock objects themselves: they’re a really useful testing technique. It just seems they’re something that is easy to use badly if you don’t pay attention."
link
Brian Marick writes: "Testing and programming are two independent technical subcultures. I think they need to talk to each other more. Within agile projects, I favor moving toward a single blended technical culture."
link
Robert Watkins addresses some common misunderstandings of the reflection mechanism and how it’s used in JUnit’s architecture.
A very complete introduction to using JUnit effectively.
link
Vincent Massol writes: "Pattern Testing is the concept of automatically verifying the good application of architectural/design patterns in code. It uses AOP to perform this feat."
link
William C. Wake writes: "Test-Driven Development is a style that says ‘write a test for a small bit of functionality, write code to make it pass, refactor, and repeat.’ In a way, the ‘test’ part of the name is misleading. TDD does produce tests in the sense that they are written to verify whether something works, that an expected answer is defined in advance, and so on. But they’re not tests in the way a tester would seek – they’re written for the programmer’s purposes. That they are mostly somewhat useful as tests is in a sense a happy side effect."
link
Simon Harris writes: "I’ve seen a few blog entries around of late demonstrating nifty things you can do to achieve setup/cleanup in your unit tests using statics or classloaders etc. And whilst I admire the creativity and ingenuity, I have to say that just like testing private methods, to me it smells."
link
Brian McCallister provides two solutions to the following problem: "AspectJ incremental compiler requires manual intervention to do a compile. It acts like a daemon and tracks its state in memory. It supports stdin recompile commands or watching the timestamp on a flag file. The real problem is that we want to be able to do a fast recompile (incremental) from an IDE so we can run unit tests frequently. This is more or less incompatible with how incremental works in iajc."
link
Brian Marick writes: "Michael Feathers asks for a way for tests to substitute their own mock classes for any class used, however indirectly, by the class under test. That would be simpler than refactoring to pass mocks around in the code under test, though perhaps, in the long run, less desirable."
link
Cedric Beust writes: "Why does a TestCase get instantiated as many times as it contains test methods?"
Followed by a discussion on the pros and cons of static initializing of test methods, and how to use the setUp() and tearDown() utilities.
link
Sam Newman writes: "Matt Raible has encountered a performance issue with his JUnit tests, and is advocating the use of static data to construct his Spring ApplicationContext. I think in this specific instance he might be justified in his choice (I’m nothing if not pragmatic) but I am always extremely cautious in allowing the use of a shared environment between tests."
link
Matt Raible writes: "I discovered an interesting thing today about Spring and my JUnit tests. I noticed that the VelocityEngine I was setting on my PositionManager was getting initialized once for each test* method in my Test. This means that since my PositionManagerTest has 10 test methods – it would load the context 10 times."
link
Bruce Eckel writes:
"For the 4th edition of Thinking in Java, I’ve been experimenting with ways to take better control of JUnit testing. My primary interest is in automatically generating the JUnit code itself to minimize the effort of the programmer.
One approach is to use JUnitDoclet, which automatically creates frameworks of JUnit code for various classes. This is certainly a step in the right direction by eliminating all the redundant code generation, but [..] it would be nice if the programmer only needed to write the essence of the test code rather than write or even navigate around the JUnit code. In addition, it would be nice to be able to put the test code right next to the code that was being tested, so you could more easily keep track of and change the code. Finally, it would be helpful if the programmer rarely, if ever, has to look at all the JUnit code, but rather is able to just focus on the essence and assume that everything else will be automated."
link
Christian Sepulveda writes: "I was working with a team that had been gradually adopting agile practices, but the developers were resistant to practicing Test Driven Development. At one point, I decided to start tracking how much time was spent compiling code, running the application/debugger, re-establishing the context in the application, observing a result and then closing the application. The developer would think about what he observed, make code edits, start the debugger and repeat the cycle. I observed that it took four minutes on average to run the cycle of compile, launch debugger, find context, etc. This would be done an average of eight times per hour; the remaining hour was spent thinking and making edits."
link
Christian Sepulveda writes: "There have been many discussions about the appropriateness of the term "tests" in describing the unit tests created during test driven development. Most of the debate has centered around the overloaded use of the term "test". For many, the expectation of testing is to discover bugs. There are also many forms of testing, such as usability testing and exploratory testing. Generally, I think the traditional role of a tester (and most forms of testing) are about the act of discovery."
link
Mike Clark writes: "I write a goodly number of shell scripts because, well, you can do a lot of automation with a low-tech shell script. So I have enough of these buggers now that I can’t remember if they all work. In other words, I have more than two scripts. And I feel this twinge of fear every time I tweak one of them."
link
Michael Feathers writes: "I don’t care how good you think your design is. If I can’t walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you’re paying a price for it."
link
Andy Lester writes: "Automated testing is the #1 investment we can make in software quality today. Here’s a simple example of one simple test accidentally uncovering an existing bug. The code is in Perl, but applies to any project in any language."
link
GroboClown writes:
"One common issue I’ve seen come up in extreme programming pertains to linking bugs to their corresponding test(s). While the test fails, the bug stays open, and when the test passes, someone should examine the bug to see if it’s ready for closing.
I developed a simple system for marking tests as related to a bug using a logging-like API."
link
Jeffrey Fredrick writes: "I had an interesting experience a couple of weeks ago that brought home the influence of developer testing on trust in someone else’s code. After reflecting, I think that being able to show an effective base of developer tests is — or should be — the most influential proxy for quality code."
link
Bob Lee writes: "I have a few tricks up my sleeve that don’t demand a great deal of effort (no need to mock up InitialContext for example) but that do result in performant and maintainable tests. [..] Cutting out the network and minimizing the amount of test data has really paid off on my current project. My entire suite of JDBC test cases executes in under a second."
link