1.1.8 supports debugging a test as a QuickFix
I just release a new version of Max that adds a “Debug” quick fix to the error markers.
I wanted to take a second to reflect on this feature. When lighting a bonfire, you can pour large amounts of petroleum products on the wood or you can build from a small fire. In business, venture capital is the equivalent of kerosene. I’ve chosen to go the other route, to bootstrap from a small product.
The critical early transition when lighting a bonfire is when one twig doesn’t just burn, it gets another twig burning as well. Two become four. Pretty soon the exponent takes over and you have to stand back or lose your eyebrows.
The twig stage requires constant attention and lots of tweaking or the fire will go out. JUnit Max is in the twig stage. It seems to me that this feature, taking 3.5 days of development, doesn’t fit this model well. Users have suggested several interesting new features. I try to turn something around every day, but I stayed focused on this too long. I should have put it on hold and turned around something else quick.
How did it happen? First, I decided it was time for automated tests for Eclipse functionality. So far I have manual functional tests, but I felt guilty about such a stone-age process. I spent two days getting the first test running. It was definitely not worth it, not at this stage. Two more days of user feedback would have been more valuable to the product. Shame is not a good criterion for prioritization.
The quick fix itself took a day and a half. In Eclipse, it is often complicated to programmatically invoke functionality that is simple to access from the user interface. So in this case–all I wanted to do was set a breakpoint on a function, run Eclipse’s JUnit in debug, and delete the breakpoint when it was hit. I had a lot to learn to get this working. The result is ~100 lines of reasonably simple code, but getting there was not straightforward.
Enough reflection, on to the next feature, which will be generating markers for succeeding tests. This should make it easier to track Max’s progress without interrupting your attention.
Reading this reminded me of Jim Shore’s story of voluntary technical debt when creating Card Meeting.
It sounds like you had two different things:
1. paying off technical debt by writing tests for eclipse functionality (2 days)
2. quick fix debug (1.5 days)
With the benefit of hindsight would you have skipped the tests and still have implemented the quick fix feature?
If not now, when would have been a better time to start adding automated tests for the Eclipse functionality?
I’m not sure whether delaying a feature two days for marginal immediate benefit was a good idea or not. The last possible moment to add functional tests is just before the first defect a test would have caught goes into production. Since it’s not possible to predict this moment accurately, I’d rather stay on the conservative side. I also want to take good care of my early customers by responding to their feedback. Hence the dilemma.