They say if it's not broken, don't fix it. So why are we running tests on tests on tests that aren't business-critical? There's an art to testing beyond just striving to get 100% coverage. In fact, over-testing can actually hamper your progress more than help it. Meanwhile, Chuck's wondering why it's not possible to have a union of enums in GraphQL.

In this episode, Chuck and Robbie discuss some tech frustrations, lessons for the React community, why Ship Shape implemented spam traps, and a whatnot on all things alcohol, sports, Friends, and Robbie's (seemingly endless) truck saga. 

Key Takeaways

Quotes

[26:52] - "There are things that warrant tests and things that don't and there are good best practices for writing them." ~ @rwwagner90 [https://twitter.com/rwwagner90]

[33:44] - "Sometimes people will just chase the goal of as close to 100% coverage as possible and then you end up with a bunch of egregious tests along the way." ~ @CharlesWthe3rd [https://twitter.com/CharlesWthe3rd]

[34:00] - "You need to test what's business-critical. You can do the other tests if you have the time. But there were a lot of tests that really didn't even check anything. And it's kind of arbitrary — you got that coverage, but you weren't doing anything." ~ @rwwagner90 [https://twitter.com/rwwagner90]

[36:32] - "Cypress is a great example of having integration testing in context where you can get visual progression testing too so [you] have some understanding there." ~ @CharlesWthe3rd [https://twitter.com/CharlesWthe3rd]

Links