Hacker News Reader

> 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.

The general tone of your comment is non-constructive, lacks accuracy and appeals more to your status as "working in V8" than to real reasoning. It is a shame that it is so high in this thread. :(

You may have some good points, but just by reading your comment I can't get them.

If you have Google money and work on compilers, surely tests are more important than for say, a B2C app with lots of UI.

So many developers are so myopic that they can’t imagine a scenario different enough from their lived experience that people would want to do things differently.

When people say “in the real world” they really mean, “in my insular world”

I totally agree with you on this one! The tone is absolutely immature and frankly disgusting. I would never hire a person with this kind of attitude, frankly because it is the ultimate creativity-killer in a team.

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...

Sorry for the harsh tone--probably an overreaction--but I think creativity is not the primary variable to optimize for in software development. I recognize that this opinion is a product of where I've gotten stuck in the software stack.

However the OP's advice was basically "don't write tests because they slow you down." They even said that 100% code coverage was "a really bad idea". The OP's attitude was flippant, dangerous, and IMO, stupid. Don't follow this advice.

We're all human and overreact, so no worries. I agree Creativity may not be primary always, but it definitely needs space to co-exist with the more logical-perspectives. After all, at some point in time people would not even be creative enough to come up with solutions like TDD etc.

Having said that, to be more OT. I agree with you regards the code coverage. However, the quality of Tests should be raised, as i would rather be in a position where people are aware that stuff can break and be on their toes, then to have false sense of confidence with 100% code coverage using poorly written tests (for example, tests so complex they need testing on their own).

And sometimes, it is more important to get an MVP out there, and collect the users feedback then the actual tests.

My point, its a dynamic world, and it doesn't hurt to listen to each other more!

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.

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

Let them write the comprehensive test suite, then. Your reasoning is a classic context for YAGNI.

> 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.

Tell that to a gamedev company.

As a counter, in this thread [1] a Rare employee says they follow TDD and it's revolutionised their development process.

[1] https://news.ycombinator.com/item?id=14802333

A CRUD app being written for the nth time does not require the same coverage as something as complex as the JVM.

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.

OK, so don't then. You are still in a bubble, important or otherwise. You can't expect me to throw out the service manual for my old Volvo because NASA wouldn't build a space probe to those standards.

Are you suggesting that the Linux kernel is unit tested? Last I checked, I couldn't find them. And discussions online say the same (e.g., https://news.ycombinator.com/item?id=9543336 and https://news.ycombinator.com/item?id=9544306). Kernel bugs tend to show up in userspace.

Fortunately, integration-oriented projects have arisen more recently such as https://kernelci.org/ and https://github.com/os-autoinst/openQA/

Anyhow, it would make me a bit sad if the v8 team is writing unit tests tightly coupled to the implementation. I've messed around with the codebase and I didn't see tests like that - could you point to some?

https://cs.chromium.org/chromium/src/v8/test/unittests/

The ones I glanced at appear to test output without much mocking, which isn't as tightly coupled as unit tests commonly end up.

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.

Enterprise software being known for its code quality.

I find a lot of enterprises follow TDD.

Oh yeah, some are extremely vulnerable to predatory TDD evangelists. You won't find many functional programming ones though.