this post was submitted on 03 Mar 2024
36 points (90.9% liked)
Programming
17326 readers
238 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Automates tests definitely work, but the downside is it requires the developer to be proactive, and the effort put in writing tests is non-trivial (and its easy and common for developers to write bad tests that give false positives).
Hmm I think you're looking for a technical solution to a non-technical problem.
Sometimes it's possible, I think
Depends on what you consider technical. I don't see this as much different than how type systems prevent type errors.
Take your example of adding a field to an entity. Just because you've made that code change doesn't mean other code should be using it. Who should be using it and how is determined by the business rules.
Also your interest in ensuring it is "properly" used is impossible to enforce. What's considered proper even for existing code can change over time.
Yes you're right. Sorry it wasn't clear from what I said before, but that's what I am saying too. The point is, if such a change is made, it should explicitly address every code that uses that entity who just added a new field. When I say "address", I mean that the user must at least be forced to "sign off" and explicitly saying a part of the code does not need to be changed due to this change. One possibility is explicitly declaring that a field is not used.
I hope this makes it clearer.
But no matter what you do, you're asking for something that will need to be manually done. Your tests should be done, and they should be reviewed. It will solve the problem you have and many more.
Just like type systems prevent you from type errors that you may otherwise write unit tests for, I don't see it unviable to have something that protects from the errors I mention.
In fact I think my solution might be in particular use of the type system, which I am experimenting with right now.
Having unit and automated integration tests backed by both requirements and high code coverage. As a lead I can verify that not only you made the change to support the requirements though these unit tests but also a really quick verification that other functionality may not have changed based on your large scale change. Helps a lot for significant refactoring too