Submitted 11 months ago by nitefox@sh.itjust.works [bot] to programming@programming.dev
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?
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.
What does “FE” stand for in this context? Sorry if it’s obvious, I just don’t see anywhere that it’s actually written out.
frontend
It’s very hard to start writing tests for a codebase that was not tested while it was being written.
“Be more careful” is obviously just wishful thinking, but the pain apparently hasn’t become bad enough for the need to better quality to have become apparent to everyone.
When people say “we can’t test the UI”, there’s often a reason that they are reluctant. One reason can be that they think you want to test through the UI, and write slow and cumbersome end-to-end tests. Those tend to become unmaintainable at record speeds, and if you’ve experienced the amount of work and aggravation that can cause, you tend to become reluctant. When you ask for ‘integration tests’, this might be the thing people are hearing.
That being said, there’s plenty of ways to test UI code locally, at the unit and component level. Depending on your tech stack, of course. Those types of tests you can just start creating without a big investment. In a codebase that’s not tested, that can be difficult, but try and make the changes you need to make to isolate logic, so it can be tested as a unit test. It’ll give you better code, and teach you a lot about structuring code so that you separate responsibilties.
Just add them. You’re a developer and automated testing is one of our tools. A woodworker wouldn’t ask permission to sand.
This is terrible advice. Communication is the solution.
Then I will be scolded for wasting time adding tests
Sounds like you need to answer back with numbers.
Calculate how much time is needed for writing tests.
Then calculate how much time was spent writing ineffective code, then add the amount of time it took to rewrite that same code.
I guarantee the latter amount will be more.
Just do it, whenever you fix a bug, add a test case for it, the cost is not going to be noticeable. You may choose to not upload the test suite right away, but wait until someone notices and asks you about it.
Don’t. You really can’t for most of it. At best, you can test whatever utility functions you have. The FE can and will break more in design than anything else, and that will never get caught by tests.
That said, try a wholistic approach. Playwright requires you to run the back end too, so you get a proper test suite going, instead of jest or whatever.
Yeah I don’t think unit testing would be useful. I don’t think though that integration tests etc are useless though, more so now that it is possible to test the UI states too. I didn’t know playwright to be fair, I read it “automatically” generates tests? Maybe I did misunderstand
It doesn’t generate them, you still have to write them. Ignore the marketing, look at the actual docs, same as any other framework.
There’s a few other frameworks, I just prefer playwright because I’m used to it.
There’s a VS Code extension that records the steps you took and creates the test for you. But more often than not, you would have to make some changes too.
who did you ask? Write the UI Tests for your debugged components anyway. Tests are part of development.
I voted you up, but this is tough. I write tests at work when they’ll help me, but nobody else maintains or creates them. Except for the tests that the boss created and insists that everyone run.
I haven’t pushed terribly hard for my tests, but it’s pretty obvious that I wouldn’t get any traction if I did, and I’m picking my battles.
So while I agree with “write your tests anyhow”, it’s a lot harder than it sounds, and a lot less successful than a proper testing strategy that’s embraced by the team.
It’s pointless if they get mad at me for “wasting time” writing tests and nobody maintains or write them.
Tests are about building confidence in that code changes are safe. Having good test coverage frees developers from having to worry about unknowns. The phrase “be careful” is nearly directly opposite to good test coverage. “Be careful” says “worry about breaking things because we don’t have high confidence when we make code changes.” That is a huge signal that test coverage should be increased. And what effort would that take? Take a sprint or just a day or two in the next few sprints to focus on writing tests.
Real world annecdata: one of our biggest customers, a global megacorp, said they no longer worry about upgrading our software because it no longer fails in unpredictable ways like it used to. Do you know why our customers now have that confidence? Because we deliberately focused on increasing test coverage. Increasing test coverage helping secure high value deals that our sales team spent a lot of time and effort winning.
platypus_plumba@lemmy.world 11 months ago
You need to create a list of incidents that reached customers. Create a matrix that has the incident ID, the link to the incident documentation and the type of test that would have caught the incident.
Then they’ll see that their incidents would have been caught by the tests you want to. push instead of an angry customer.
nitefox@sh.itjust.works [bot] 11 months ago
They know. We have had a production website being literally unusable, sucking up a lot of resources for a bug.
We have a client which is MAD cause the project is riddled with bugs, but the solution somehow is paying more attention. Except that it clearly isn’t feasible to pay more attention when you have to check, recheck and check again the same thing over and over… They say it’s a waste cause you can’t catch UI, and you will spend the same amount of time NOT writing tests; obviously this is all crap, but they somehow think they are smarter than google or any other small or big company that do write test
lysdexic@programming.dev 11 months ago
By definition, automated testing means paying more attention, and doing it so well that the process is automated.
Show them a working test that’s catching UI bugs. It’s hard to argue against facts.
onlinepersona@programming.dev 11 months ago
Who’s saying this? Other programmers or management?
Programmers might listen to reason, but might be very set in their ways. Some that don’t want it might even sabotage it and write crap tests that don’t do shit like test that
true == trueor skip all of them. Know your crowd. If it’s a crowd that like copying the latest and greatest, quote something google or facebook did or said. If they’re old-school, find some old-ass programmer that loves tests.Management listen to money unless they’re incompetent. Calculate the time it took to resolve certain bugs, estimate the hourly-rate of people, compare that to how much time it takes to write tests, but make it clear that not all bugs can be caught. Maybe even find an article or blog from some manager/CTO/technical lead at another company talking about how bug count dropped or something.
If it’s a free for all, add tests yourself.
If they’re overbearing, bro, look for another job. A bad culture fit is a bad culture fit and there’s no need to fight that. It’ll be a learning experience too: not everybody can be convinced and not every company is for you.
glitches_brew@lemmy.world 11 months ago
Maybe a response to their ‘solution’ would be to ask them if they were under the impression you weren’t being careful/paying attention before the bugs occurred?