Floehopper

thoughts on the bergy bits of life

July 1
“ Try to avoid using before blocks or setUp methods – especially in an abstract test class. Just call the method that does the setting up directly from the example. Don’t leave me to guess there might a magic method in a different class that is being invoked before the test even runs – that’s just not fair.

Let your examples flow by Dan North.

If the inventor of BDD says so, it must be true ;-)
+
“ Should examples/tests/specs/whatever be DRY? […] In a word, no. DRY zealotry is a classic example of an over-adherence to Best Practices, which as James Bach argues are a bogus concept anyway. Let your examples flow by Dan North
June 30
“ Lean Product Design is about maximising discovery. Everything is an experiment, and if you don’t learn anything it wasn’t useful. This is analogous to writing software, understanding and articulating requirements, user experience workshops, designing effective tests, identifying corner cases. Foster an environment where it’s ok – in fact encouraged – to try new stuff “just in case”, or run two or three ideas in parallel to see which one fits best. That isn’t waste, it’s a good discovery habit that you can position as due diligence. Read up on innovation techniques and creating an innovative working environment. Your programmers aren’t building cars – they’re designing cars. Let them. Make it fun. Learning to Lean by Dan North
+
“ Lean Supply is about minimising inventory. This is analogous to deferring decisions, doing enough up-front analysis and design but no more (and certainly not none, otherwise you starve your supply). Have a nominal backlog of features but don’t bother planning out 3 months of detailed Master Story List (that term should never have made it out of the gate). Learning to Lean by Dan North
+
“ Code is difficult to test when classes are tightly coupled, are entangled by hidden dependencies like static methods or singletons, or don’t clearly distinguish between internal implementation details and peer objects (dependencies, policies or notifications). To unit-test classes like this, it can be tempting to use tools that use clever class loader tricks and bytecode manipulation to break the tight dependencies. But by using tools like this you lose one of the major benefits of unit-testing in the TDD process: rapid feedback on the internal quality of the software. Allowing tests to drive development by Nat Pryce. Seems relevant to partial mocking…?
June 26
“ I see this all the time. Developers caving in to marketing guys, managers—the business side. The developers perceived as negative and resistant by the business guys and the business guys labeled as clueless and lying by developers. It’s an on-going war. ‘Us against Them’ with no hope of reconciliation. Using Numbers to Communicate - in the Spirit of Agile by Linda Rising and Barbara Chauvin
June 13
“ My point is that we can’t look at testing mechanistically. Unit testing does not improve quality just by catching errors at the unit level. And, integration testing does not improve quality just by catching errors at the integration level. The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality. The Flawed Theory Behind Unit Testing by Michael Feathers
June 12
“ What do tests written first (unit or acceptance) accomplish? Express how we know something has worked. Can we do this with meetings? If we did, what might it look like? Would the very act of trying to express success critera for a meeting have a profound effect on how a meeting progresses? Test Driven Meetings by Brett Schuchert
May 30
YouTube - Most Terrifying Video You'll Ever See Climate Change: The cost of inaction outweighs the cost of action.
May 23
free cartoons as "social objects" How to make money by giving away your intellectual property.