TDD gets in the way of writing code that doesn't work. Experimental, toy, research code doesn't need to work. Everyone prefers to believe they are writing research code, and don't want to be bothered about whether it solves a problem correctly.
Giving up on test-first development
201–210 of 224 posts
Re: Giving up on test-first development
#202Earlier quoted context omitted.
it's like i'm an artist. You can't tell an artist how to paint. I'm going to paint my best work when I'm allowed to choose my own easel and pallette and brushes. Let me throw some green paint on the canvas and make the trees how I wanna make the trees. Programming is more art than science.
True, if you're working alone. But 5, 50, 500, 5000 artists trying to paint on the same canvas? Then the game is significantly changed.
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar i'll take a Bazaar of 5000 artists any day over a forced Cathedral.
Re: Giving up on test-first development
#203"Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests."
In what way would it be different when doing "test-after", instead of "test-first"?
There's an inherent difficulty of writing robust, isolated and fast tests ; test-first development is not the cause here. Writing good tests is hard, and it's even harder when your code wasn't designed with testability in mind.
To TDD or not to TDD, that's not the question. You should be able, as a test writer, to see and isolate things that prevents testability: I/O, timers, threads, rand(), minimal computation time, clumsy interfaces, etc. TDD just puts these things in front of your eyes, early.
Re: Giving up on test-first development
#204TDD is not going to be a good fit for GUI development unless the application design specifically avoids the "smart UI". Because the article's author states "as I started implementing a GUI, the tests got harder to write", I'd assume his UI is indeed "smart".
Exactly. TDD is about unit testing, and unit tests shouldn't test boundaries (there are other means to test them).
Re: Giving up on test-first development
#205Earlier quoted context omitted.
True, if you're working alone. But 5, 50, 500, 5000 artists trying to paint on the same canvas? Then the game is significantly changed.
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar i'll take a Bazaar of 5000 artists any day over a forced Cathedral.
Testing practices are orthogonal to the cathedral vs bazaar idea. Linux is a great example of this. Anyone can checkout the code and work on it, but upstreaming the changes requires coordination and approval with the community.
The lessons by Raymond are also given in the context of OSS. Unfortunately it would be extremely difficult to find a team of developers that are passionate about the kind of stuff that SAP is written to solve, for example.
The lessons of Robert Martin and others are about how to be a professional developer. When you are writing software for someone else to use and they pay you money to do it, it is your reaponsibility to think about quality, extensibility and maintainability. It is not your job to express your self.
My take is that the point of TDD being so rigid is that a professional should always follow best practices, not just when they feel like it or when it is easy or convenient to do so. But TDD is an ideal and sometimes, or maybe even most of the time, there are externalities that make you fall short of that ideal.
Re: Giving up on test-first development
#206Earlier quoted context omitted.
Can you give an example? I'm struggling to think of a language where that can't be worked around without bending the original code.
public class Foo { private static class Bar { public void someMethod() { } } } Unit test someMethod. More realistic, concrete examples are harder to describe because they involve an interaction over time between a somewhat vague problem description and exploration of a solution state space, where the abstractions chosen are fluid and slide around before they get into a good shape. I, for one, tend to write code from…
As far as I understand it, someMethod can be tested using reflection. I haven't tested it, though.
Re: Giving up on test-first development
#207Most people probably felt the same way after only a "few months" (best-case, perhaps less) of practicing TDD. And certainly TDD is harder as you approach the GUI, you want to test in vague ways which don't break with every change. If you thoroughly test all of the underlying behavior, implementing a GUI is typically incredibly trivial because everything beneath it is known (and proven) to work. Most of the article is…
Also check out Bob Martin's response: http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTD...
Re: Giving up on test-first development
#208Justin Searls' "The Failures of Intro to TDD" is relevant to this discussion: http://blog.testdouble.com/posts/2014-01-25-the-failures-of-...
Re: Giving up on test-first development
#209Earlier quoted context omitted.
yeah, well you just test what you own anyway, for other stuff you could just grab some kind of dummy response and use that for testing your manipulation of that data, but of course you have to trust your customers endpoints to return the data in the correct format because that is out of your control.
Trust, but verify. We've always found that writing your own smoke tests for the other guy's code saves a lot of head scratching and the game I like to call Blame Tennis, when each side insists that any new problem must be in the other side's stuff because surely WE haven't broken anything.
These have become known in Pivotal as "frenemy tests". Poke a remote API to see that a) it is running b) it hasn't dropped a world-stopping change.
Typically run as a pre-build sanity check when you have remote integrations.
On some Labs projects we've written extensive request tests and stub services based on documentation, then handed those to the upstream service. Usually there is some angst at this point, being the first time that any kind of TDD suite has turned up to ask awkward questions.
Re: Giving up on test-first development
#210Earlier quoted context omitted.
If you don't know what the code is supposed to do, how are you writing it?
I'd translate this as "don't use tests for proof-of-concept code". At least not when success is easily observable.
In XP settings this is called "spiking" and is recognised as an entirely legitimate tactic.
The point of spiking is that you don't know enough to TDD. You are outside the sweetspot where TDD is tractable.
The key to spiking is that once you come with a plausible approach, or have a conceptual breakthrough, you stop, backtrack and then switch back to TDD.
Like everything else in mature software engineering, agile or classical, it requires sustained discipline.