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

331–338 of 338 posts

Re: Write tests. Not too many. Mostly integration

#331

Post by dep_b »

hacker_9 wrote: post #141
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…

What you describe is the typical mindset against TDD, it's difficult to explain the benefits, and really you just have to experience them for yourself. Changing your mindset is difficult, I know, why change what works right? My only tip is to keep an open mind about it, as TDD benefits are often not apparent to begin with, they only come after a couple of days work or weeks or months later or even years later. You fi…

How to implement an SDK that performs real-time manipulation of audio without really knowing how to describe the correct result using TDD?

Only when I understand the problem, the SDK and the expected result I could start writing some tests.

TDD seems to be for business applications where you're using tried and tested technology to implement new problems.

Re: Write tests. Not too many. Mostly integration

#333

Post by breatheoften »

Vinnl wrote: post #325
breatheoften wrote: post #314

Earlier quoted context omitted.

Brittle tests seem not useful in general though aren't they? I'm not sure its necessarily true that brittleness must correlate with height in pyramid or execution time -- in my experience brittleness correlates with selenium more than it does pyramid height (that's a statement about selenium more than it is a statement about any particular category of testing pyramid). Its possible to write very useful non-brittle te…

No they're not. But yes, Selenium is brittle. That said, Google engineers actually did some investigation into this, and although I think their methods were probably a bit heavyweight, they did conclude that it's mostly RAM use that leads to brittleness. [1] https://testing.googleblog.com/2017/04/where-do-our-flaky-te...

Interesting thanks for the link!

I’m curious how many tests were in the small size range for that chart which provides evidence to show the size-flakiness correlation holds in tests that use tools associated with higher than average flakiness...

I’m also feeling like I want to have more clarity around the mechanism for measuring flakiness — the definition they use is that a test is flakey if it shows both failing and success runs with the “same code” — does “same code” refer to a freeze of only the codebase under test or also a statement about change to the tools in the testing environment ...?

I wonder what the test suites for tools like selenium/WebDriver look like ... do they track a concept of “meta-flakiness” to try and observe changes to test flakiness results caused by changes to the test tooling ...?

Re: Write tests. Not too many. Mostly integration

#334

Post by Vinnl »

breatheoften wrote: post #333
Vinnl wrote: post #325

Earlier quoted context omitted.

No they're not. But yes, Selenium is brittle. That said, Google engineers actually did some investigation into this, and although I think their methods were probably a bit heavyweight, they did conclude that it's mostly RAM use that leads to brittleness. [1] https://testing.googleblog.com/2017/04/where-do-our-flaky-te...

Interesting thanks for the link! I’m curious how many tests were in the small size range for that chart which provides evidence to show the size-flakiness correlation holds in tests that use tools associated with higher than average flakiness... I’m also feeling like I want to have more clarity around the mechanism for measuring flakiness — the definition they use is that a test is flakey if it shows both failing and…

Yeah, good questions, the post leaves some to be desired. And meta-flakiness tooling actually sounds like it could be really useful!

Re: Write tests. Not too many. Mostly integration

#335

Post by edwinyzh »

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"…

Anyone can give me an example or explain a little more about "Structure your code so it is mostly leaves."?

Re: Write tests. Not too many. Mostly integration

#336

Post by jamie_ca »

edwinyzh wrote: post #335
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"…

Anyone can give me an example or explain a little more about "Structure your code so it is mostly leaves."?

Leaves in this context would be classes that have no dependencies.

If you need to create an object, can you pass the name of the class in? Or can the object be created elsewhere and passed in fresh? If you're making a call to a remote service (even your local DB) are you being passed a proxy object?

All of these references can then be provided as a test double or test spy, so long as they are strict about the interface they provide/expect, and you can exhaustively cover whatever internal edge cases you need with unit tests.

Don't _forget_ the integration tests, but my personal opinion is that it usually suffices to have one "success" and one "error" integration test to cover the whole stack, and then rely on unit tests to be more exhaustive about handling the possible error cases.

Re: Write tests. Not too many. Mostly integration

#337

Post by sobani »

hacker_9 wrote: post #181
viraptor wrote: post #168

Earlier quoted context omitted.

> Any refactoring done is safe from regressions, because of your comprehensive test suite. As much as I like the idea of TDD, I have a problem with this part. When some refactoring is needed, or the approach changes, it seems like you have two choices. One is to write the new version from scratch using TDD. This wastes extra time. The other is to refactor which breaks all the guarantees you got before. Since both the…

I'm not sure what approach you've described here, but it isn't TDD. In the case of adding new features to existing code, as you are continually running tests you will know straight away which you have broken. At this point you would fix them so you get all green again before continuing. In this way you incrementally modify the codebase. Remember unit tests are quite simple 'Arrange, Act, Assert' code pieces, so refac…

refactoring != adding new features.

Also some refactorings are easier with tests, some are harder.

The kind @viraptor mentiones is the kind that spans more than one compoment. For example when you decide that a certain piece of logic was in the wrong place.

The kind of refactoring that becomes easier is when you don't need to change the (public) API of a component.

Take for example the bowling kata. If you want to support spares and strikes and you need extra bookkeeping, that's the easy kind of refactor where your tests will help you.

But if so far you have written your tests to support a single player and now you want to support two players who play frame by frame... Now you can throw away all the tests that affect more than the very first frame. (yes in the case of the bowling kata, you can design with multiple players in mind, but that's a lot harder in the real world when those requirements are not known yet)

Re: Write tests. Not too many. Mostly integration

#338

Post by mannykannot »

juandazapata wrote: post #307

Unit tests force you to think about good design. Integration tests don't. If you only use integration tests, you'll end up with a big ball of mud. Certainly I wouldn't want to touch a codebase by the author of this post.

This is exactly the wrong way round. Only by thinking about interfaces can you avoid a big ball of mud, and interfaces are what integration testing tests.
Post reply on HN