151–160 of 338 posts
Earlier quoted context omitted.
No offence, but you work in a bubble of sorts. In enterprise we are absolutely expected to run against a wall - preferably fast.
I find a lot of enterprises follow TDD.
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…
Because there isn't proper way to write unit tests for GUIs for example. They can only test parts of its behavior, not everything, and are too brittle to any simple UI/UX change.
I'm going to say this is poor, if not outright dangerous, advice. I'd argue the opposite: every time the code changes, it would be great if a test somewhere broke.
Hell, if the tests originally were for a gigantic class with a ton of mocks but the code changed so there was lower coupling and the dependencies were injectable or separated in different modules, the tests should be changed.
> even a strongly typed language should have tests
Indeed, yet I've seen so many people in the strong typing "camp" mentioning "the compiler catches some bugs right away!" as an advantage, which always makes me think "... and?"
> It doesn’t matter if your button component calls the onClick handler if that handler doesn't make the right request with the right data!
... But there should be another unit test for that handler, checking that it's using the right request with the right data.
In general, I agree with some points and disagree on others.
Earlier quoted context omitted.
> as much as you can into static helper functions and most of the rest into dumb private stateless functions In our work we use C# and it is very hard, even next to impossible to make a static class pass a code review - given it's not for extension methods (which I hate... why not be explicit about the first parameter and stop acting as a part of the class ). They just tell us to use IoC and move to the next point. I…
C# is the new Java... facepalm
> 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…
> What in the. serious. fuck. Of course tests test implementation details. Because _implementation details_ are where the goddamn bugs are. Testing is about testing inputs and outputs, not implementations details. Bad testing checks if you called this function or if you accessed this data. Good test checks that for a given input you get the expected output. > Please don't follow the advice of this. It's total crap. T…
> 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.
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…
If you are writing a library write unit test, if your app mostly binds two libraries together unit tests are meaningless, write integration tests.
I think unit tests are good for testing logic, and integration tests are good for testing functionality. Lots of complex logic? Then write lots of unit tests. Got a service that just wraps a database? Then you're going to want to write a lot of integration tests.
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.
> 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…
> What in the. serious. fuck. Of course tests test implementation details. Because _implementation details_ are where the goddamn bugs are. Testing is about testing inputs and outputs, not implementations details. Bad testing checks if you called this function or if you accessed this data. Good test checks that for a given input you get the expected output. > Please don't follow the advice of this. It's total crap. T…
This type of attitude is creating a culture where everyone is "to scared to learn" by being to scared to comment on things, or even to ask a simple question.
So sad to see this...