this post was submitted on 05 Dec 2023
57 points (100.0% liked)

Programming

17432 readers
217 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

We are in a very funny situation where I just spent two weeks fixing FE bugs and there are so many left. I asked to add integration tests but the answer was “no”, cause we can’t test the UI and all of that.

So the proposed solution was to be more careful, except I’m careful but testing whole website parts or the whole website is not feasible. What can I do?

you are viewing a single comment's thread
view the rest of the comments
[–] friend_of_satan@lemmy.world 24 points 11 months ago* (last edited 11 months ago)

Show them the Beyonce Rule part of the Google SWE book.

We are often asked, when coaching new hires, which behaviors or properties actually need to be tested? The straightforward answer is: test everything that you don’t want to break. In other words, if you want to be confident that a system exhibits a particular behavior, the only way to be sure it will is to write an automated test for it. This includes all of the usual suspects like testing performance, behavioral correctness, accessibility, and security. It also includes less obvious properties like testing how a system handles failure.

We have a name for this general philosophy: we call it the Beyoncé Rule. Succinctly, it can be stated as follows: “If you liked it, then you shoulda put a test on it.” The Beyoncé Rule is often invoked by infrastructure teams that are responsible for making changes across the entire codebase. If unrelated infrastructure changes pass all of your tests but still break your team’s product, you are on the hook for fixing it and adding the additional tests.