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.
When people say “in the real world” they really mean, “in my insular world”
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...
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.
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!
> 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.
Tell that to a gamedev company.
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.
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?
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.
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 find yourself testing implementation details just so you can make sure you get that one line of code that’s hard to reproduce in a test environment. You really want to avoid testing implementation details because it doesn’t give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code.
What in the. serious. fuck. Of course tests test implementation details. Because _implementation details_ are where the goddamn bugs are.
> ... Maintaining tests like this actually really slow you and your team down.
That's the whole _point_. It slows you down in the short term but it keeps you from experiencing a full-on system meltdown when everything seems to be breaking at once.
Please don't follow the advice of this. It's total crap.
If you've never worked on a system that has survived more than 3 years, sure, go right ahead, run against the wall. But when you work on a system survives 5, 10 (V8), or 20 years (HotSpot JVM), then you really, really want to have good tests.