It was a great event today at @co_up in @berlinjs meet-up and here are my sides about wru which accordingly with today meeting means where are you, directly out of SMS syntax.
Enjoy ;)
behind the design
My JavaScript book is out!
Don't miss the opportunity to upgrade your beginner or average dev skills.
5 comments:
Hey man,
I see you're fascinated by TDD.
Yet my question is: does it really solve the problem?
Let's see this not-so-imaginary problem: the user needs a convenient way to access Nokia Maps data from his iPhone.
Of course, Gaia is great, yet unfortunately, the solution to this is not just Gaia itself, but rather an application built around Gaia.
Now the specification of this application isn't defined by you. You can talk into it perhaps to an extent, but at the end, you'll have a specificaition, which you can turn into a test.
Is the application good if it doesn't fail any of those tests and they cover all the relevant parts of the specification?
Also, what if you failed to recognize some inter-relatedness (like: a place for abstractions) in the specification? What if the system fails to deliver as such isn't addressed in the system?
It still passes all the tests.
I've written partly about it in the long comment here:
http://www.infoq.com/articles/specification-by-example-book#view_77233
"a place for abstraction" is over engineered for real world use cases but still, you can have that without problems. Create a place out of an empty representation on the map and you are done.
In any case, wru aim is to bring people that do not test at all their code into "at least something works as expected" world without any TDD paranoia and once again, this blog is not about my daily basis work, it's about programming!
Place here didn't mean geographical place.
My problem with TDD boils down to a few points basically:
- It does make people think that they can go a good job independent of the actual result (eg. tests passed, yet the application isn't good), and this is especially a case where everyone does the best possible yet the end result isn't mindblowing so to say.
- You don't test against humans, you test against a computer, which sometimes makes the actual system fail miserably in real-life situations
- I'd like to question TDD- based code's flexibility. I found FitNesse to break under any real-world use cases for example
- Tests maintained by the developer himself (herself) tend not to clean up APIs, and if combined with missing design (prev. point), zoomout tends to be missing.
- Personally, for me, hardcore TDD breaks my code cycles of 1-1.5 hours where I could think straight
While for API-kind of development, especially with complex business logic, I do write unit and acceptance test and ask everyone to do so, and it's a great tool to imagine an API (although only as a side activity), it's also great sometimes to explain (and come up with) specification details I doubt if it should be used as a substitute for traditional design technologies (pattern languages, design languages, other half-explicit languages) as it is today.
- it does make people to think what they have developed ... at least what they think they did works with a proof
- you test against what you thought you coded ... fair enough, since real world case and humans problem will come later, at least you can guarantee a behavior
- flexibility/agile must work and tests are a way to proof stuff is "working out" as expected
- test must be maintained/updated as soon as API changes or even before so the proof things work is still there
- time is against software quality so it's a weak point unless you don't want to live out of a "maintainance contract" using customer ingenuity
Most important thing ever: I have never talked about TDD in my slides or, generally speaking, in this blog. TDD is for ExTreme Development and since perfect software does not exist yet anywhere in this world, I am not the one that tells people "hey, you do TDD, it must be best software ever" ... I am here the only one that is trying to make tests easy: wru!!!!
Post a Comment