Hacker News Reader

My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

It's a bit of a tangent but I've also observed this. So much that I've started calling it the "cucumber-complex".

Once infected the team not only writes excessive unit-tests to validate things like that a method-call to 'foo' does indeed call the method 'foo'. But they also wrap these unit-tests in quite elaborate parsers in order to "express" them in pseudo-english.

The hilarious (cucumber-specific) aspect is how they usually start by writing their tests in plain RSpec or Test::Unit and then go at implementing the parser to make it "tell a story".

I wouldn't be so quick to write off Cucumber et al.

A few benefits:

- Sometimes business users will contribute and use these scripts (admittedly in only some teams and less often than supporters would claim);

- They help with analysis and design as you are forced to question exactly what behaviour you would like to acheive;

- They keep the developer focused on the feature rather than, for instance, building some big fully featured class or library which wont be used;

- They encourage outside in testing so you get good but pragmatic testing for features at each layer of the application;

- They act as a free living documentation on the system;

- They are more lightweight than they initially appear.

I would rather have lots of BDD style tests than the silly tightly coupled unit tests loaded with expectations that you describe erlier in your post.

the most important bit, i think, is that a cucumber test suite is documentation that cannot go out of date, because if it does your test breaks and you have to fix it, thereby updating the documentation aspect of it.

> Agile is the current day water fall model. I mean in spirit on in factual procedures.

I think the problem is people sticking to a particular process, thinking it's the definition of "Agile". Rather than responding to change and the individuals in the team.

As our team was growing to the point where planning sessions were taking several hours we switched to just in time planning. A couple of developers could give a lightweight estimate of work at any point. Planning became just a 30min discussion with stakeholders to prioritise work, and we'd dig into implementation details as a team when we actually started working on something.

This would obviously not work for everyone. My point is that we responded to the problem and adapted our process to change in the team and environment. It's the 4th point on the agile manifesto http://agilemanifesto.org/

Retrospectives should give an opportunity for teams to do this if done right.

Somebody should let them know that unit tests are for us, not them.

someone should tell everybody that it is not us or them, but we.

unit test help us but not them? How can that be true if they pay your salary. If tests make you more efficient, so becomes the/their team (we/them as you please). In the end even the customer is influenced by good unit tests, or any other improvement for you. Bottom line: stop thinking us vs them, think we.

p.s. Not a manager, I am a programmer like you.

>>Agile is the current day water fall model. I mean in spirit on in factual procedures. >>My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

Whenever I read opinions like this all I hear is "Wah wah wah. I'm old and I don't like learning new things. What's wrong with the way I've always worked? Wah wah wah, managers."

The problem with unit tests and a certain type of manager is that they see the unit test coverage as something that must be managed to be as close as possible to 100%, when this is arguably a waste of effort.

Agile has been around for many, many years. I think the Agile Manifesto is a teenager by now. There are a lot of people well into their careers who have "always worked" the so-called Agile way.

Sure, but I don't see why an effort to study how successful teams work and distil in a methodology needs to be derided by other programmers.

Most managers I've worked with just wanted some transparency and predictability to the process. Waterfall failed to provide that and now the industry is experimenting with Agile.

I find it distasteful when developers grumble to each other about having to perform basic tasks such as unit testing (TDD, BDD or whatever). I've worked with far too many 1/10x developers to know some kind of process is required to keep them on the straight and narrow.

There is no magic bullet, but I think it's time we stop snorting in derision at the industry's attempts to reduce the unpredictability of building (and maintaining!) complex software.