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?
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 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.
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.
Bonus points if you can calculate the amount of money lost from an unavailable application, then add in the amount of money lost from the confidence your customers are losing in that app.
How do you calculate those numbers though?
It’s not like your colleagues will be keeping track of how much time they’ve wasted writing ineffective code. If anything, they’ll try to hide that by arbitrarily inflating sprint points etc.
I’ve worked in environments like that and the issue almost always isn’t that people wouldn’t LIKE it if there were tests, it’s that they
- Don’t want to have to learn something new in order to do the same job they’re already comfortable with
- Are worried that if they convince management to let them invest X amount of time into doing something that will improve productivity, they’ll be expected to be more productive in the future
And of course, all of this for no extra money. Unless you work at a place where management prioritzes developer happiness over how many sprint points the team can knock out every week (and those are rare), the sad truth is that it’ll likely be about as popular as leftover food growing mold in the community fridge.
Exactly this. They aren’t for the company, they’re for you to have confidence that your shipped code isn’t going to blow anything up.
who did you ask? Write the UI Tests for your debugged components anyway. Tests are part of development, and if you cant then you write your components wrong.
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.
deleted by creator
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
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.
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.
So you’re probably not going to be able to swing getting a project greenlit to test everything on your frontend, partly because your management seems a bit stingy, and partly because it’s probably not the best approach to do this kind of thing anyway.
To the claim of that you can’t test UI: only if you’re not creative enough. Behavior can 100% be tested, and is worthwhile to test, while UI looks can be verified with screenshot tests.
How I would probably approach this would be:
- Get some very basic test execution infrastructure in place. Ideally it runs in CI, but if you have to do it in the dark, then just make sure you can run it locally
- Try to refactor parts of the code you touch to actually have its behavior testable - do this as a part of any ongoing work of navigating the codebase
- Whenever you add functionality, add a test to verify it. Write the test first if you can
- Whenever you encounter a bug, write a test asserting the behavior you want, then fix the bug such that the test gets green.
Following these steps should successively put the codebase into a healthier state.
Another perhaps even more valid option would be to look for a better job - working in headwind from management is not recommended, as it will deteriorate your mental health.
Good luck!
