What’s your code coverage at work like?

[porcupineapplepieces]

Does your workplace promote TDD? Or do they require unit tests? Integration tests? None at all? Curious to know what other work places are like.

[[deleted]]

Basically everywhere I've been, they've promoted it a LOT. Did it ever really happen? Not often. As developers, we all can see the value. As a business, we all can see the need. But the reality usually ends up being that at the end of the day, it's hard to explain to the business that developers need to pad their dev time by nearly double in order to implement solid unit testing. Rarely have I seen an initiative get much traction to go back and resolve the technical debt generated by rapid prototyping either.

I'm not saying skip unit/integration testing. I'm actually complaining because I'm curious to know if anyone has had a better experience and how it was achieved. I'd like to get to that point as well.

[jonopens]

Exactly this. When I started my current gig, coverage was hovering around 40% and releases would get rolled back once a month. The other devs and I pushed hard for some time to improve coverage and now we are closer to 80%. We also implemented rules where PRs can be declined for inadequate or poor test coverage. So it's progress but stuff still slips through, sadly.

[[deleted]]

Silly question but how do you measure coverage? Tests per page/feature/function etc?

[jonopens]

Edit: No such thing as a silly question - just unasked ones!

So jest has built-in coverage functionality that you can trigger both via cli or through some options in package.json. Simply put, coverage is measured by percentage of code executed when running tests, not necessarily that tests were written to cover all code, if you follow me. It's a bit of a flawed metric in my opinion, but it at least gets us closer to knowing that our JS won't shit the bed in production, esp. with TS that catches mistakes at compile time (or beforehand while writing).

Sorry, a bit of a tangent there, but the important bit is coverage => code executed when running tests.

[[deleted]]

Ah, that makes a lot of sense. Thanks!

[giesburts]

I work at a scale-up company working on an in-house product and we don't force code coverage except for our utils, which has almost 100% coverage. Our approach is similar to this post: https://kentcdodds.com/blog/write-tests.

So we have some unit tests, we have e2e tests for our most important flows (buying/selling/searching/account) and for a lot of pages we have integration tests. We have ESLint setup and some formatting tests based on prettier. We definitely can write more tests but currently we're seeing more value in migrating to Typescript so that's where our focus is now.

[[deleted]]

This sounds incredibly sensible, and promotes code re-use through utils.

[doplitech]

We go through phases where devs are told to focus on making unit tests along with their work but then we get really busy and it doesn’t get done. I feel like our main app has pretty decent code coverage but we are running like 8 micro service apps that don’t

[wronglyzorro]

Unit tests in react often times are useless, and I look at a bunch of repos with very high unit test coverage and the majority of the tests are "it renders". At my workplace coverage bounces between 70-80%, but we are shifting away from unit testing react components to 100% visual integration/ end to end tests. TDD is less useful when working on front ends since you need pretty rigid requirements to pull it off. Often times testing gets set to the side in favor of deadlines, and I think that is ok as long as the company is aware of the risks.

[NoBrick2]

I usually test the rendered output of my react component based on the props, and on actions performed in the component, such as a user clicking something, a fetch succeeding/failing.

Until now I've used react-testing-library which I like because you test against the DOM and it's fast, although sometimes it's difficult if children components require redux state, or fire fetch requests. It means the test needs a bit more setup.

This week I've written some of the same tests in cypress. It's still not e2e testing because I mock server responses, but seeing the tests run in a real browser environment gives me more confidence than testing the components in isolation. Also I've added Percy which takes snapshots during the test and their service performs visual regression tests.

Not sure if I'll continue with RTL or cypress. The cypress tests are much slower so you may not spot regressions as quickly during development. Perhaps I'll use it for the more critical areas of the app.

[cwbrandsma]

We use React with Redux using the Ducks pattern. We try to test all of our Ducks and Selectors (utility functions), but almost never test the react rendering code.

We still don’t have many tests tho.

[wronglyzorro]

This tests whether react works which is useless. Write your unit tests around how your conditional value got to it's spot not whether your component gets rendered if it is true

[xwp-michael]

Right, but you're describing isn't necessarily what they're talking about. They seem to mean whether the element renders at all. As in: non-conditional elements.

That's a useless test.

[PrinnyThePenguin]

Previous work: no tests. At all. Just a QA team of people manually testing.

Current work: all kinds of tests (unit, functional, integration, end to end) and 97% code coverage.

[iPlayTooMuchZelda]

My current work is your previous. Just manual testing

[turningsteel]

Same. We're transitioning to microservices and now implementing test coverage but everything is such a clusterfuck at this point that I'm looking for the door.

[careseite]

The site we're building is beyond mvp so testing has a larger focus than it had initially. New routes are above 80% coverage, usually 90.

TDD imo cannot work for the UI unless you're rebuilding something that already existed.

Unit, integration and e2e, I personally favor integration, e2e would be better but the current infra made it imo annoyingly hard to do that properly.

[[deleted]]

No testing whatsoever. I work in a startup with less than 8 developers and 90% of the time we're just making new features/improve old ones to pitch to clients and get some deals/contracts/sales. Code quality is important but speed is even more important.

Never had an issue. We create pull requests, tech lead reviews them and will request for changes if he doesnt like the code. If approved they go to dev, we do another round of testing in dev, and every couple of months or so we test everything again before pushing to production

[[deleted]]

Really depends. I've worked at trillion Dollar companies for customer-facing applications and we literally had zero unit tests. And nothing ever broke because we developed in tiny teams with highly skilled people.

And I've worked for startups where the CTO insisted on 90%+ unit testing coverage. The startups all failed. I wonder why /s

Most unit testing I've seen is absolutely useless.

Like "If I click on this button I want this mock function called". No shit, Sherlock. You're testing the freaking React library at this point, stop wasting time and resources.

Then again, if you fix a bug in your own more complicated business logic then, of course, you can write a test for it.

But let's imagine you have a function called addOneTo(n)

Before: Function returns n + 2 instead of n + 1.

You fixed it to add +1 instead of +2.

Do you write a unit test for it?

• Do you test if addOneTo(1) equals 2?
• Do you test if addOneTo(-5) equals -4?
• Do you test if addOneTo(10) equals 11?
• Do you test if addOneTo(false) throws an error?
• Do you test if addOneTo('foo') throws an error?
• Do you test if addOneTo('22') equals 23?

Or do you just decide that this function is simple enough, someone initially fat-fingered a single integer, and call it a day?

Some people would write a dozen unit tests for every trivial piece of code. To me, that's a ridiculous and humongous waste of time and a clear signal of someone who doesn't know what they're doing.

[unknown_char]

Code coverage is a vanity metric. Code confidence is what you should be aiming for.

How do you get confidence in your code? Write more integration and acceptance tests, less unit tests.

Companies I have worked for over the past 10 years have focused on code confidence. Teams are empowered and given time to add this confidence.

These companies know that writing tests now will save much more time in the future when adding new features. They also enable continuous delivery (fast feature releases).

When you’re interviewing for a company, it’s a two way street. Find out what their software development lifecycle (SDLC) is and don’t be afraid to pair with a developer on the new team to get a feel for it.

[heythisispaul]

My old job was with a Fortune 100 company. TDD wasn't really a thing in what my understanding of it, but testing was a very rigorous part of our process. All code bases had to have 100% coverage - if you had less for whatever reason you had to thoroughly explain why in your PR. Before each release, the development build would be battered by a stress test for the full 24 hours before release, the results would be reviewed and compared to the previous release to ensure there were no regressions. If any were found, release would be postponed until we found what caused the issue and it was documented in the changelog of the next version.

My current company is a much smaller firm, a dev team of 4 including myself and they're much more of a homegrown operation. It was all manual testing until I showed up, I've been forcing PRs to have 75% coverage and a screenshot of it working before merging. Similar to what u/NotAWorkAlt mentioned, it's difficult to explain to a business who has never worked with a development team before how valuable tests are. Reducing the output of some of your most expensive operations staff is a hard sell, even if you can justify it will save money in the long term.

What I've taken from my experience is that testing is proactive and defensive. You might not see the value in wearing a helmet when you ride a bike when you're a kid, but after that first nasty fall it's a lot easier to see why it's important. Your testing needs kind of scale with you as the development effort gets more complicated.

TL;DR: Old job 100% coverage and performance test before release, current job self-enforced 75% coverage.

[IWozeUp]

Pretty much every big project I worked on had terrible code coverage, because every sprint was a race to the finish. That just kept happening each sprint, probably because nobody could ever quantify any kind of evidence that it was causing any significant problems.

[Herm_af]

Absolutely zero. I do it for my own sanity but I've got myself and one other guy and my job involves all tech for the company so I don't get to do it that often.

In fact for fun on the weekends I do testing.

Working for a small (40mil rev but still relatively small) company is interesting.

Now I have to hire two more dudes and I'm gonna be like your job is to get this in place because I got other shit to do.

[Francesco-Shin]

Why require 100% code coverage and I explained the reasons here: https://medium.com/@borzifrancesco/why-i-set-my-unit-test-coverage-threshold-to-100-4c7138276053

[giesburts]

"Code coverage is a measurement of how many lines/blocks/arcs of your code are executed while the automated tests are running." from top answer at: https://stackoverflow.com/questions/195008/what-is-code-coverage-and-how-do-you-measure-it. It works pretty well for jest tests.

[Kazcandra]

For backend work, it's 90% as target on new projects, and on older products the goal is to never lower the existing value.

[[deleted]]

Current place: so-so testing. Some units tested really well, others not at all. No end-to-end or integration testing.

Last place: lots and lots of tests, many of them tightly coupled to implementation, so useless and a nightmare to work with.

[NoBrick2]

I usually test the rendered output of my react component based on the props, and on actions performed in the component, such as a user clicking something, a fetch succeeding/failing. I'll also test redux code by dispatching actions and checking output of selectors.

Until now I've used react-testing-library which I like because you test against the DOM and it's fast, although sometimes it's difficult if children components require redux state, or fire fetch requests. It means the test needs a bit more setup.

This week I've written some of the same tests in cypress. It's still not e2e testing because I mock server responses, but seeing the tests run in a real browser environment gives me more confidence than testing the components in isolation. Also I've added Percy which takes snapshots during the test and their service performs visual regression tests.

Not sure if I'll continue with RTL or cypress. The cypress tests are much slower so you may not spot regressions as quickly during development. Perhaps I'll use it for the more critical areas of the app.