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

131–140 of 338 posts

Re: Write tests. Not too many. Mostly integration

#131

Post by oddlyaromatic »

TeMPOraL wrote: post #109
pjmlp wrote: post #82

Earlier quoted context omitted.

Is GUI code that 0.1%? Because I am always keen to understand how to TDD GUI code and I don't mean the data model behind the pixels.

I think so. I don't know how to unit test GUIs either.

I saw an enjoyable talk recently about snapshot testing. I don't know too much about testing generally but it seems like it could be relevant: https://facebook.github.io/jest/docs/en/snapshot-testing.htm... is the general idea but it doesn't have to be confined to jest/react

Edit: Slides from the talk I saw: http://slides.com/bahmutov/snapshot-testing

Re: Write tests. Not too many. Mostly integration

#132

Post by away2017throw »

titzer wrote: post #129

> I’ve heard managers and teams mandating 100% code coverage for applications. That’s a really bad idea. The problem is that you get diminishing returns on our tests as the coverage increases much beyond 70%... I call bullshit. I work on V8, on JITs and WebAssembly. 70% coverage for these code bases would be absurdly low. We would never ship code that is that poorly tested, and you shouldn't either. > You may also fi…

No offence, but you work in a bubble of sorts. In enterprise we are absolutely expected to run against a wall - preferably fast.

Re: Write tests. Not too many. Mostly integration

#133

Post by cjsuk »

quickthrower2 wrote: post #117
cjsuk wrote: post #97

Earlier quoted context omitted.

There is some cargo culting there but it's mostly correct. Helper is a code smell as it's a sign of "we don't know what the responsibility of this is or what to call it so we'll just chuck a load of shit in this file and call it a helper" . The methods in should belong to something and live on that class, not in an external class. RequestExtensions is more shit than the original solution. Extension methods are even w…

This is a matter of taste not fact. In functional languages the style is compositional with static functions everywhere. It works well. The keeping data and methods together thing is one approach. Sometimes it's great. Sometimes unnecessary. For example would you argue against string formatting helpers? Or would they need to be written to an interface and added to myriad DI bucket lists?

It's not that simple and it's not a fact. I'm an advanced user of functional languages as well and have written an entire scheme implementation before. I only semi-agree. That's slightly disingenuous representation of functional languages which have more than a few pitfalls. They certainly aren't the silver bullet and they really do not scale to the same height and complexity of the problem domain as the OO languages do due to the nature of the abstraction you describe. Nothing is particularly explicit. I'd rather take the compromises of OO over the maintenance problems of a functional language.

String formats are data so they would be stored as constants so that they are interned. They can be stored in a const class which is a static class with no methods i.e.:

   sealed class StringFormats {
       public const DateFormatX = @"...";
   }
Also string formats for example tend to be owned by the respective objects so you can add overloads to the object to provide certain arbitrary representations. If the translation between an object and the string representation is complex, then you're really serializing it so that should be an abstracted concern.

Re: Write tests. Not too many. Mostly integration

#134

Post by titzer »

away2017throw wrote: post #132
titzer wrote: post #129

> I’ve heard managers and teams mandating 100% code coverage for applications. That’s a really bad idea. The problem is that you get diminishing returns on our tests as the coverage increases much beyond 70%... I call bullshit. I work on V8, on JITs and WebAssembly. 70% coverage for these code bases would be absurdly low. We would never ship code that is that poorly tested, and you shouldn't either. > You may also fi…

No offence, but you work in a bubble of sorts. In enterprise we are absolutely expected to run against a wall - preferably fast.

The bubble happens to be at the bottom of everything everyone runs. If we--or kernel folks for that matter--applied the advice of the article to our development practices, our system meltdown would be your system meltdown.

Sure, you have requirements from management. So do architects and engineers for building bridges. Yet they still have a duty to build bridges that don't fall down.

Re: Write tests. Not too many. Mostly integration

#135

Post by pwim »

titzer wrote: post #129

> I’ve heard managers and teams mandating 100% code coverage for applications. That’s a really bad idea. The problem is that you get diminishing returns on our tests as the coverage increases much beyond 70%... I call bullshit. I work on V8, on JITs and WebAssembly. 70% coverage for these code bases would be absurdly low. We would never ship code that is that poorly tested, and you shouldn't either. > You may also fi…

The author of the post agrees with you that library code is different:

> I should mention that almost all of my open source projects have 100% code coverage. This is because most of my open source projects are smaller libraries and tools that are reusable in many different situations (a breakage could lead to a serious problem in a lot of consuming projects) and they’re relatively easy to get 100% code coverage on anyway.

Re: Write tests. Not too many. Mostly integration

#136

Post by w4tson »

away2017throw wrote: post #132
titzer wrote: post #129

> I’ve heard managers and teams mandating 100% code coverage for applications. That’s a really bad idea. The problem is that you get diminishing returns on our tests as the coverage increases much beyond 70%... I call bullshit. I work on V8, on JITs and WebAssembly. 70% coverage for these code bases would be absurdly low. We would never ship code that is that poorly tested, and you shouldn't either. > You may also fi…

No offence, but you work in a bubble of sorts. In enterprise we are absolutely expected to run against a wall - preferably fast.

Running against the wall in the enterprise is what management expect but in my experience it’s down to developers “holding their nerve” to use the proper process (unit tests, PRs etc).

It’s not even necessarily experience because I see the experienced devs do this all the time. But your good developer will know that when the feature is so important that it needs “rushing”, aka straight to prod or, skip QA etc then that’s exactly the time to stand firm and write those unit tests instead of throwing crap over the wall and making it next weeks defect.

Re: Write tests. Not too many. Mostly integration

#137

Post by titzer »

pwim wrote: post #135
titzer wrote: post #129

> I’ve heard managers and teams mandating 100% code coverage for applications. That’s a really bad idea. The problem is that you get diminishing returns on our tests as the coverage increases much beyond 70%... I call bullshit. I work on V8, on JITs and WebAssembly. 70% coverage for these code bases would be absurdly low. We would never ship code that is that poorly tested, and you shouldn't either. > You may also fi…

The author of the post agrees with you that library code is different: > I should mention that almost all of my open source projects have 100% code coverage. This is because most of my open source projects are smaller libraries and tools that are reusable in many different situations (a breakage could lead to a serious problem in a lot of consuming projects) and they’re relatively easy to get 100% code coverage on an…

The thing is, everything that survives becomes a library, as someone will always find a way to try to reuse it.

Re: Write tests. Not too many. Mostly integration

#138

Post by al2o3cr »

TeMPOraL wrote: post #35
hinkley wrote: post #3

Good lord. Why integration tests? I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. So they try to write E2E tests…

> The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. The biggest problem I see with people advocating for tests and employing TDD is that they do change how they write code to accommodate tests. This leads to inclusion of lots of…

    That said, if you go for functional style in OOP, i.e. 
    shoving as much as you can into static helper functions and
    most of the rest into dumb private stateless functions,
We had this at a company I worked at a while back - dozens of modules with nothing but static functions that all took a first argument of the same type. If only there was some kind of METHOD for declaring a whole bunch of functions that operated on the same data...

Re: Write tests. Not too many. Mostly integration

#139

Post by pjmlp »

cjsuk wrote: post #90
pjmlp wrote: post #82

Earlier quoted context omitted.

Is GUI code that 0.1%? Because I am always keen to understand how to TDD GUI code and I don't mean the data model behind the pixels.

We use Ranorex for this: https://www.ranorex.com/

Interesting, thanks for the link.

Re: Write tests. Not too many. Mostly integration

#140

Post by lkitching »

hacker_9 wrote: post #121
lkitching wrote: post #99

Earlier quoted context omitted.

> that method is now dependent on the static class and you don't have any control over it. I don't see how you have any less control over it than any other code you wrote. If you don't want it to write log statements, then don't do that. Most static methods are small and pure so don't need to write log statements anyway. > Now your testing will dirty whatever database you're using, as well as run 10x slower. I've nev…

I think you missed my point, it's not about the logging framework, its about the fact you don't control an external dependency during testing. Unit tests are meant to be reproducible, meaning they are done under controlled conditions. > Most static methods are small and pure This is very assuming, tests are a way of being specific about your intent.

> its about the fact you don't control an external dependency during testing

If your code is structured using small static functions, you don't have any dependencies in the first place, just arguments you are passed and transform. You will probably create interfaces for external services you depend on, but you can avoid needing to mock them if you express the transform directly.

> This is very assuming

I'm not assuming anything, since I wrote the static method and I also decided to call it, presumably for the result it calculates. Your argument appears to be that static methods could contain bad code but that applies to all code you depend on.

Post reply on HN