this post was submitted on 12 Sep 2023
17 points (94.7% liked)

Web Development

3441 readers
11 users here now

Welcome to the web development community! This is a place to post, discuss, get help about, etc. anything related to web development

What is web development?

Web development is the process of creating websites or web applications

Rules/Guidelines

Related Communities

Wormhole

Some webdev blogsNot sure what to post in here? Want some web development related things to read?

Heres a couple blogs that have web development related content

CreditsIcon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
snowe@programming.dev
erlingur@programming.dev
Ategon@programming.dev
17
Avoiding tunnel vision when debugging (self.webdev)
submitted 1 year ago* (last edited 1 year ago) by rayquetzalcoatl to c/webdev@programming.dev
8 comments fedilink hide all child comments
 

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 are viewing a single comment's thread
view the rest of the comments
[–] towerful@beehaw.org 7 points 1 year ago

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.