BDD / TDD criticized

,

Like democracy, science sucks but we haven’t found anything better yet :wink:

1 Like

Haha, so true. Applies perfectly to both indeed.

Yes yes, first there was chaos, then came the universe. Better not to return to dust too soon. But anyway, we can do better than TDD and hail the devine priests that appear on youtube.

Erik Meijer is not a proponent of TDD, on the contrary. See his presentation on agile at youtube or read comments on Uncle Bob’s twitteraccount f.e. He is working on ML now, and compares it to TDD here:

https://queue.acm.org/detail.cfm?id=3055303

https://twitter.com/HenrikJoreteg/status/1037208424340246528

2 Likes

From Lamport’s “Who Builds a House without Drawing Blueprints?”

https://archive.li/2zZKy#selection-293.30-305.209

1 Like
1 Like

Starts really good, liked it immediately and I’ll read it all.

I fully agree with the premise – we can get very fixated on languages alone and that’s a problem. What we should be paying attention to are IMO the runtimes. I like Elixir a lot and it got a lot of things right in terms of language design and minimal stdlib API but if it wasn’t for the runtime it would probably never take off as it did.

There are many other possible selling points of languages – the portability of pure Go code, the memory safety of Rust, the DSL-friendliness of Racket, and maybe in the future an OTP-like clone in Pony, who knows? Languages that formalize the work like Haskell, OCaml and Idris can be extremely useful as well (I keep wanting to learn OCaml and can’t find the time and I am sure I’ll regret that one day!). Also overall, Go, Rust and OCaml seem very fast. Nothing wrong with orchestrating nodes in these languages inside an OTP supervisor, for example.


As I work on more on more different systems with time I grow to appreciate the value of good flowcharts and proper RDBMS / SQL reporting tools – and data migration, and reverse-engineering tools as well. Also concepts like How to create beautiful pipelines on Elixir with Opus (more options linked here: Flow based programming in elixir - #15 by amacgregor) caught my eye lately and I am due to researching them properly.

I personally am less and less interested in arguing with anyone about Python, Java, PHP, Ruby, C++ or whatever the holy language war is about during that particular day. I want to get my work done well and to be proud of it.

…Who knows, one day I might like BPMN as well. :icon_wink:

I placed this and the previous copy/paste from Lamport in the context of this thread, where the subject is "BDD / TDD criticized’. Of course the scope of Lamports articles is broader. But it’s all about what should go before coding (and that is not writing tests but thinking/writing/designing “above” the code level). Call it big design upfont. :wink:

Btw Donald Knuth in an interview http://www.informit.com/articles/article.aspx?p=1193856

But that is no more than an opinion of a famous computer scientist. Lamport provides substantiation.

2 Likes

That’s exactly the average environment of most commercial programmers though. Treading carefully in a team setting inside a complex project – via unit tests – is a basic common sense, not a fashion trend or cargo culting. It helps you to not break other people’s work and to progress your backlog tickets.

Agreed. :023: When you are building something by yourself then you have a bigger freedom overall then it’s really pointless to tread as if you are in a minefield. Just create and experiment! The time for automated validation tests usually introduces itself when the time comes – because at certain point you have too many moving parts and you need the extra peace of mind that you can progress with confidence.

(I imagine that’s like building your own mini-car in the garage and starting to gradually tighten the nuts and bolts once it starts getting into workable shape and you are ready to drive it for a test run.)


To me TDD is a badly overdone religion. It makes perfect sense in a particular set of circumstances but it’s very far from that universal truth it’s sold as.

Vehemently disagree. Besides common sense is not “what is right” but “what most do”. A Dutch saying: “Whose bread you eat, whose word you speak”. Stems somewhere from the bible.

1 Like

Can’t edit my reaction anymore. Add: for extensive reasoning behind my disagreement see for example the very start of this thread, with a link to “why most unit testing is a waste”.

6 posts were split to a new topic: Rust - Go Comparisons

https://twitter.com/HenrikJoreteg/status/1098829955822018562

https://twitter.com/dan_abramov/status/1098560575712432128
Dan Abramov ‏ @ dan_abramov 19 uur19 uur geleden

In particular I’m curious about the emotional investment into a particular testing methodology. Could it be because they’re all not that great, and so we develop devotion in order to feel our choice is justified?

Becca Nelson Bailey ‏ @ beccaliz 18 uur18 uur geleden

I think many of us have been told that good testing practices are what separates “good” programmers from “bad” programmers. We have given testing an almost moral value, but we don’t have an absolute standard to judge by, so the standard becomes our own practices.

1 Like

A plea to do testing:

It took about five years until I understood how testing works (for me). And I can’t imagine doing any programming without anymore. My key to success with testing was to not see it as something I do in addition to my code but just as part of it. I write tests first because I first wanna define how my not yet written code can be used. If it is hard to think about a simple test for a new function, I first refactor my existing code thus I can come up with a simple test. Because if it’s hard to write a test for something, most likely that stuff will be hard to understand and use for other programmers (or myself in the future).
So, the key point here is, not even think about how I will implement the function before I have a definition of how to use it then. For example, if I have in mind that I will use a struct for something, tests often drive me to use a simple list.

When I have to continue on the code I haven’t touched for a while, I first run
mix test --trace --seed=0 and immediately have a specification of the status quo.

When I look out for something on Github, I first read the tests to understand how I can use and eventually change/extend that code. If there are no tests, or in case I can’t understand the tests, I skip that repository.

Other than that, of course, I feel so comfortable when there is a trustworthy test suite if it comes to refactoring existing code.

I gave up arguing about TDD, I just do it and enjoy a much stressless life.

A plea for requirements engineering before coding: BDD / TDD criticized. Lamport makes the distinction with TDD clear in his paper.

1 Like

As I wrote, testing is part of my way of developing applications. This doesn’t mean that I don’t do requirements engineering up front. Just the opposite is true. But, when I start coding, I start with a test.

Often the tests / the fact it is hard to find a proper test / shows me when my upfront design has flaws in details. And in this case, I tend to rework my blueprint rather than question if I’ve waste time writing the tests.

Start without a blueprint is wrong. Do it without testing is wrong. Testing just for the sake of coverage is wrong. Strictly following a blueprint for any price is wrong. Doing it right needs a lot of practicing and failing is more likely than success.

So, I totally support your plea for requirements engineering :wink: but at the same time, I try to encourage people to do proper testing.

Can I hope that we can agree on, that one is just as important as the other?

This can happen when you’re finding out what you really want. Testing shows “how sloppy your thinking is”. Happens to me also, by far the most requirements I find out without testing however. Often my tests are end to end, as they give the most ROI. I am going to put a small js thing on github in a short while. The code contains an extensive list of requirements and as far as needed comments in the code explaining the how. Not an extensive testsuite. The code should be understandable by reading requirements, the code itself and the comments in the code. Tests would not add value with respect to understandability I think. I would accept and maybe even write tests myself per requirement if it would not hamper refactorings, and if it did not cost so much extra time. I would not trust a testsuite that much as the guarantees given by the results are not quite 100%.

Discussion on twitter with Ron Jeffries etc.

https://twitter.com/Hillelogram/status/1107754119627001859