[throwaway_f8ed]

Disclaimer: I mean no offense.

I am yet to see one production-ready real-world code example from such gurus of design of the past. Kent Beck, Bjarne Stroustrup, Scott Meyers.

I think that in 2017 you shouldn't be entitled for your opinion about design if you have nothing to back up your cases. Sadly, this also covers me with this throw-away account, but bear with me for a while.

When they started their journey the world was different and chains of thought that led them to their current points of view are long obsolete.

We are living in a different world with different values. My own experience with integration tests led me to believe that I cannot afford to skip on them. There are far more moving parts nowadays and it's better to know that something introduced breaking changes from tests than from angry customers. Something along long chain of dependencies that you did not even consciously knew you are depending on.

Now, some guy who is known only for some books he wrote in times of yore comes in and tells me I am doing it wrong, only on basis of his non-existent experience and unfounded authority? We already know what comes out of unsoliticed advice like that. We wasted decades on OOP modeling, UML and tons of other things that never came off.

There are now widespread ideas that he either conceived or popularized, but even these mutated to the point of unrecognizability.

How about we will move on?

[dang]

Given the context, this comment is a personal attack. That's not ok here and I've banned the account.

If you really meant no offense, you need to work harder at giving others the benefit of the doubt and watching out for ignorance masquerading as knowbetterness. We all need to work on these things, of course, but comments that go below minimum levels are not welcome on HN.

https://news.ycombinator.com/newsguidelines.html

[murftown]

No offense taken, but let me add this:

I too initially felt a bit weird about the insinuation that "Integration tests are a symptom of poor design", but it's worth pointing out that that's not really the title of his FB note: it's '"Unit" Tests?'. * In fact, going back and reading it a 2nd time, I can't really find anywhere where he's saying you're "doing it wrong" if you're writing integration tests - in fact he says he writes them himself. I think he's just relating a realization he had, that a test should perhaps only be considered an "integration test" if there are systems it depends on that we're not sure are bulletproof yet, i.e. we wonder how well they "integrate". For example, even our "Unit" tests rely on relatively complex systems, e.g. the interpreter of the scripting language you're using. This fits with my (limited) understanding of software testing.

It did seem like he was kind of presuming that pure functional implementations (e.g. of the Transactions objects in his example) would be so much better and more airtight that they probably wouldn't even need testing, but I'm not sure he was really implying that; perhaps he was just using that example to convey that once you really feel like you know the behavior of a subsystem, you take it for granted, and the tests right above it no longer have to "worry" about "integrating" it.

* To be fair, I guess it is KentBeck himself that posted this with that name, so that is a bit "considered harmful"-ish. Not sure what else you'd call it though. Anyways, I enjoyed his reflection, and didn't find it that preachy myself.

[discoursism]

I think that caveat that you cite is operative. Although I take it in a slightly different direction than the author.

The point at which integration tests become important is not really a question of bullet-proof-ness. It's a question of complexity. When the underlying system has sufficiently many moving parts/degrees of freedom, at some point, you need to see what it does when your system interacts with it in a certain way.

Generally this is not necessary for integers. In most domains, you're not going to come upon any boundary conditions in the way they are transformed or compared. Transactions are also a pretty simple concept with little in the way of moving parts. If your system doesn't rely on their behavior near boundary conditions, maybe they are transparent enough that you don't have to test your system's interaction with the transaction concept. But there are a lot of underlying systems that are not like that.

[murftown]

I think that's right, that other than bullet-proof-ness, the boundary conditions and interfaces between nontrivial subsystems matter a lot and need to be integration-tested. Glad you pointed that out.

[vlunkr]

I feel like some of these comments are just reading the title and immediately posting their disagreement. I'm with you, he says he writes integration tests himself. There's nothing controversial about this post, it's actually pretty interesting.

[mannykannot]

After reading the article, I thought the person posting to HN had either misunderstood it or misappropriated it for his own agenda - but then I saw that it was apparently posted by the author himself.

[KentBeck]

There's a challenge finding the right headline when posting to HN. My last few posts had very literal headlines and went nowhere. I amped this headline up a bit while making sure it was still honest and, looky here, it got more attention. Now I have to decide how I feel about the difference.

[mannykannot]

FWIW, it doesn't bother me. Perhaps phrasing amped-up headlines as questions would forestall at least the more moderate wing of the clickbait squad?

[KentBeck]

Thank you for letting me know how I appear to you. I don't agree that my point of view is obsolete or that I am not entitled to an opinion about design. Judging what I write based on my age led to you, as other commenters have pointed out, missing the point of my post.

Your point about up-to-date examples is well taken. Finding good examples is the hardest part of technical writing for me. As I work on Facebook and Instagram I will keep my eyes open for clear examples of the same principles, because the principles really are the same regardless of shifts in technical fashion. You'll have the opportunity to learn that in the years to come.

[e9]

I am on the same page with you. In my personal experience, biggest problems occur between interaction of the modules and not so much within particular module. Without integration tests there is just no way to catch these things no matter how good of an architect you are.

[maxxxxx]

A long time ago we had Scott Meyers for a week long workshop. He definitely knew his stuff and showed a lot of real world experience. But with a lot of "gurus" I have my doubts. A lot of advice from Scrum gurus falls apart when it meets reality.

I guess the ultimate advice should be given by people like Linus Torvalds who run large projects.

[throwaway_f8ed]

I will never question that he knows language and its obscurities, but real world in his case is even more different.

Scott Meyers is a C++ guy. I will bet that nowadays most of C++ programmers are in game development, HFT or other computationally expensive performance oriented areas, and there is this data-oriented design movement which goes against almost everything he ever said. There are entire constructs of language he is proficient in that are never used in real world.

[maxxxxx]

Back then I was at a C++ shop. He definitely knew how to deal with practical problems and wasn't just a language geek. This was more than 10 years ago so a lot of ideas from then are not fashionable anymore.

[blub]

Data-oriented programming is just one optimisation technique, not a revolutionary design movement.

[veidr]

Did you really read the piece? The reason I ask is that what he wrote and what you wrote are essentially the exact same:

    I’m happy to write integration
    tests. I insist on it. But a 
    part of me registers the need 
    for integration tests as a 
    failure or limitation of my 
    design skills.

(That's how I feel about integration tests, too — which I always use.)

[blub]

Stroustrup invented C++ and he's actively developing and designing it.

He also almost exclusively talks and writes about C++, he's not telling you anything about integration tests.

You just seem ignorant by including his name on that list.

[Bob2019]

Yeah, I doubt he writes any tests at all - unit or integration.