Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write tests. Not too many. Mostly integration

blog.kentcdodds.com

Post reply on HN
Print view View original

291–300 of 338 posts

Re: Write tests. Not too many. Mostly integration

#291

Post by seanwilson »

crdoconnor wrote: post #162
seanwilson wrote: post #127

Earlier quoted context omitted.

> People just don't write comments or tests after, that's the problem. Doesn't that get caught in code review anyway though? I find being forced to write tests first can be clunky and inefficient. Also, I've worked with people who insist on the "write the minimum thing that makes the test pass" mantra which I find really unnatural like you're programming with blinkers on. TDD takes the fun out of coding for me someti…

>I find when you're writing tests first, you're being forced to write code without understanding the problem space yet and you don't have enough code yet to see the better abstractions. That's why it's better to start with the highest level tests first and then move down an abstraction level once you have a clearer understanding of what abstractions you will need.

Can you do that with TDD though? Why not just sketch the code out first before you start writing tests?

I find TDD proponents don't take into account that writing tests can actually be really time consuming and challenging, and when you've got a lot of code that is tests, refactoring your tests becomes very tedious.

Re: Write tests. Not too many. Mostly integration

#292

Post by luord »

marcosdumay wrote: post #288
luord wrote: post #272

Earlier quoted context omitted.

> So, it doesn't matter if your code is correct or not? I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. I honestly don't see the correlation. > And that leaves more time to design things right and test the stuff that actually matters. I'm not gonna get into a religious flamewar; if you prefer static typing, all the power to you and I'm not int…

> I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter. Well, that quote was your entire sentence. It wasn't out of context. So: > every time the code changes, it would be great if a test somewhere broke There isn't anything anywhere about the code being incorrect. Thus it is irrelevant. About the types, their entire point is that they save you from…

> As an example, you forgot to test if `'nos': ("", None)` yields the correct error.

It isn't in the go code either.

> There isn't anything anywhere about the code being incorrect. Thus it is irrelevant.

Why, exactly? I'm not following your inference there; again, walk me through that one.

Let me be more explicit: what exactly did you think I meant with that line? Again, I don't see how it implies that "it doesn't matter whether the code is correct".

> About the types, their entire point is that they save you from writing the tests.

Ok, this is getting circular so I'll just ask you to give me an example of a test that would be absolutely required in a dynamic language but not in a static one.

Mind you, that isn't going to convince me one way or another in the "static vs dynamic" flamewar since I subscribe to the idea that more tests is better. I'm asking mostly out of curiosity.

Re: Write tests. Not too many. Mostly integration

#293

Post by alien_at_work »

BlackFly wrote: post #106
chewbacha wrote: post #53

Earlier quoted context omitted.

One reason why is because you should be testing the public behavior of a function/class not the details. The reason for this is because the public interface is what other parts of the codebase will come to rely on. Refactoring generally shouldn’t change the public interface as it will break other pieces of code within your codebase, or other codebases if it’s a library, and other systems if it’s a network api. So, if…

I would argue you absolutely need to be testing the internal details. That is the entire point of measuring branch coverage and performing mutation testing. Unit tests are not black box tests. They need to know that for special values, the unit has to follow a different code path but still produce sensible output. Reading the documentation of a function is not sufficient to determine what edge cases the unit has, but…

I'm trying to imagine what on earth your private methods can be doing that wouldn't be affected by the public interface.

There should be no situation where the same exact call in the public interface could take multiple different paths in the private method. The only thing I can think of that could make that happen would be some dependancy, which should be mocked at the top level to control these cases.

Re: Write tests. Not too many. Mostly integration

#294

Post by seanmcdirmid »

seanwilson wrote: post #285
seanmcdirmid wrote: post #175

Earlier quoted context omitted.

Maybe writing code for exploration and production should be considered separate activities? The problem with these coding ideologies is that they assume there is only one type of programming, which is BS, the same as assuming a prototype is the same as a working product.

What's exploratory programming though? Unless you're writing something that's very similar to something you've written before and understand it well, most programming involves a lot of exploration.

Well, UX prototypes for one. In research, most projects never go into production, those that do do so without researcher code. Heck, even in a product team, if you are taking lots of technology risks in a project, you are going to want to work those out before production (and it isn’t uncommon to can the project because they can’t be worked out).

Re: Write tests. Not too many. Mostly integration

#295

Post by alien_at_work »

hvidgaard wrote: post #7
josteink wrote: post #4

Earlier quoted context omitted.

I work in a company where quite a few of the developers simply are incapable of writing anything but integration-tests. The reason? They don’t “believe” in unit-tests. They don’t think unit-testing “works in the real world”. They absolutely fail to accept that they need to write their code differently for automated testing to work well. How do you change such a mindset?

I doubt that you can. There was a study a while back, and I apologize in advance because I do not have a link, that showed projects written with unittests took significantly longer to reach the market, but with significantly less bugs. However, overall time spend on the code was less. So conclusion was that unittests are a commitment to a long term goal of minimizing developer time, and the tradeoff is that it takes…

Was this the microsoft study? I think it was a breakdown of their delivery of Vista?

Re: Write tests. Not too many. Mostly integration

#296

Post by alien_at_work »

pleasecalllater wrote: post #33

Sounds good in theory. In practice there is one problem with having integrations tests only. The test are generally simple: they pass or they fail. A unit test tests just a small functionality, so when it fails, it's quite easy to find out the problem. When an integration test fails, then we can spend hours debugging the whole stack of layers trying to find out the real problem. I had this situation once. Every faili…

For me, one of the biggest issues with integration tests is the code coverage numbers mean nearly nothing. I've seen an "integration only" tester proudly display his single test with 90% coverage. I asked him to run it again and it was 2% because a condition changed.

So this means that for all the branches your code can take, an integration test is taking one specific one at each point all the way through for that test. All over branches, through the entire call stack are unverified.

Re: Write tests. Not too many. Mostly integration

#297

Post by alien_at_work »

methodover wrote: post #25

Is there solid evidence to back up some of the assertions that have been made about testing? It feels like an area where lots of people have opinions, and there are not much in the way of facts.

Microsoft put out a study where they had done TDD or at least extensive unit testing. I don't recall the numbers but development time took longer and there were a lot less bugs. Which is what I would have expected.

Re: Write tests. Not too many. Mostly integration

#298

Post by therealdrag0 »

mannykannot wrote: post #189
moultano wrote: post #6

I'd take a slightly different take: - Structure your code so it is mostly leaves. - Unit test the leaves. - Integration test the rest if needed. I like this approach in part because making lots of leaves also adds to the "literate"-ness of the code. With lots of opportunities to name your primitives, the code is much closer to being self documenting. Depending on the project and its requirements, I also think "lazy"…

> Integration test the rest if needed . Is there any situation where there is integration, but no need to test it? You seem to be suggesting that if the leaves are thoroughly tested, nothing can go wrong in their integration, but at the same time, I cannot imagine someone believing that.

Exactly, most bugs I see are in integration, mis-matches in data-models or state. But I also work on business-y applications which tend to be more integrations than local business logic.

Re: Write tests. Not too many. Mostly integration

#299

Post by dang »

protonfish wrote: post #193
kartan wrote: post #149

So much people in this thread is talking about different domains and are not able to see that they need different rules. It is not the same creating a library that is going to be used to launch a multi-billion rocket to Mars than developing a mostly graphical mobile app where requirements are changing daily as you A/B test your way into better business value. The article has really good points and the reasons why the…

The fight against the TDD cargo cult is vicious, barely started, and far from over.

Please don't. If you have a substantive point to make, make it thoughtfully; if you don't, please don't comment until you do.

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

Re: Write tests. Not too many. Mostly integration

#300

Post by therealdrag0 »

saas_co_de wrote: post #110
throwaway5752 wrote: post #11

Why does everyone rethink a working strategy. Write lots of unit tests that are fast. Write a good amount of integration tests that are relatively fast. Write fewer system integration tests that are slower. The testing pyramid works. He even talks about it in this post, and then ignores the point of it. You write lots of unit tests because you can run them inline pre-commit or in a component build. If you integration…

the point is that blind 100% coverage cargo-cultism is not a working strategy.

Does anyone even believe in 100% coverage?
Post reply on HN