Hey guys! Sorry if this isn’t the best place for this but I couldn’t really find anywhere else.
I’ve been working for 6/7 years as a web developer full-time now, and I’m still plagued by one mega frustrating habit. When I’m working on something complex on one page, and it gets completed, I’ll fairly often get notified either by the client or my boss a day or two later while they’re testing the whole site that there’s something broken on another page.
Almost always, it’ll be down to the fix I’ve recently made.
Is there a way to avoid this kind of tunnel vision? I try to keep my code localised as much as possible, avoiding interacting with global scope and, if it’s really for one specific thing, tying it down to that page in particular, but short of testing the entire site every time I make any change… is there anything else I can do?
Thanks!
You must log in or register to comment.
Cypress tests spring to mind. Continously test all aspects of your application.
Check what your testing organization is using first. We’re using Selenium at work, except for one small team that used Cypress because they couldn’t be bothered to find out what the test of us were using, so now that team is faced with either maintaining their own version of the CI pipeline and their own tooling (and not having anyone to ask for advice) or rewriting all of their tests. Not an enjoyable choice to have to make.
Those look great! I have thought about front-end testing before but was a little unsure of how to really implement it. I’ll give this another look. Thanks!
Tests.
Target the “business logic”.
You can structure your code to facilitate unit or integration testing.
Setup tests for the key functionality. Whenever a bug gets reported, create a test or test case to address that bug, fix the bug, and ensure the test now passes.Have a staging environment, so the site can be interacted with and tested without touching anything in production.
You can push to this often, and request some help with QA to ensure nothing is broken.Have a testing environment. Again, a complete duplication of the infrastructure.
Set up end-to-end tests. These automate interactions with the entire application.
Have tests that run against key features. “Setup appropriate state, load form page, fill in form, click button, check that database entries are correct”… “setup appropriate state, check that submission summary shows correct data”.
These are quite handy, but a lot slower and fragile than unit and integration tests.There are automated testing platforms that can capture a “good” state of a website, then use image matching to ensure further runs visually match what it should look like.
These are normally expensive and finiky.Hopefully you will get to a stage with your testing that your unit and integration tests catch 90% of your potential bugs, and e2e tests will ensure the core functionality is working correctly.
Then, as you do a bunch of work, you can run your tests, see they all pass, and be confident.Finally, I will say that tooling like frameworks and typescript can catch a lot of these errors quite quickly.
However, these won’t catch logic bugs - which is what tests are for.Sometimes I step away from the screen and talk out is happening in my head.
Often times my coworkers and I will ask each other for help. Much of the time the person explaining will see the problem as they explain it to the other person. Usually before the other person has a chance to get the full explanation.
Also called the rubber duck debugging effect.
But yeah, articulating your thoughts, be it by talking or even by writing down your train of thoughts (which is a good habit to have while debugging complex issues) really helps spotting the holes in your own thinking.
Awesome! I found out this worked for me years ago when I was a lone dev. I would walk around muttering to myself. Glad to know there is a term I can use now!
If you work with a team, I’m gonna say the fault here is just as much on team management as it is you, for not having review and quality testing processes in place. If this is the case, maybe it’s time for you to become the champion for this.
You should have SOME amount of documentation for what requirements different features are supposed to satisfy, even if it’s in the form of automated testing code that exercises these requirements. Automated testing is obviously preferrable, whenever feasible, because they’re the lowest-effort to perform, and the more effort it takes to test, the more likely you’ll be to skip it.
As a more direct answer to the question, use version control to step up your own self-review process. When you’re “done” with an implementation, review the diff of every change that you’ve made, and build yourself dependency trees for the modules you’ve changed. Use this tree to identify regression testing that you need to perform, I.E. tests to run or perform by hand to ensure that existing functionality hasn’t changed.
Doing things right means you’re probably gonna spend half of your time on testing or writing testing code, and you might even feel like a lot of your time spent is redundant or wasted. It’s not. Producing quality software doesn’t mean just being smart enough to write perfect code all the time, it means investing time into BEING redundant on purpose.
