Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
But, they work on real-world codebases, which tend to have a lot of code, in a lot of files, for a lot of features.
"and bugs, and anti patterns, and bad code, and monoliths", which all can be fixed anytime if you have tests!
Also they are good for documentation, you can understand what the code suppose to do, even if it has the worst naming conventions and you do not know the language!
For me the biggest advantage is the ability to refactor without having to prey before the release! This transforms a code from a brick to a jelly bear, flexible, it can be bent to accept new features.
I like the idea of tests as documentation. I have experienced it first hand, going to the tests (unfortunately as a last resort) to try to figure out how something works, but I didn't think of it for this text.
Btw, you made me think of a brick of jelly bears... a catastrophe that can sort of work as a metaphor for some codebases out there ๐
Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
I admit, it wasn't the best metaphor I've made up :D
Btw, my comment comes after an extensive experience on legacy code with 0 automatic tests. I've seen the ups and downs of monoliths, the pros and cons, and one thing is for sure, once you go tests you don't go back. They are not a silver bullet, they just make our life easier.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"and bugs, and anti patterns, and bad code, and monoliths", which all can be fixed anytime if you have tests!
Also they are good for documentation, you can understand what the code suppose to do, even if it has the worst naming conventions and you do not know the language!
For me the biggest advantage is the ability to refactor without having to prey before the release! This transforms a code from a brick to a jelly bear, flexible, it can be bent to accept new features.
I like the idea of tests as documentation. I have experienced it first hand, going to the tests (unfortunately as a last resort) to try to figure out how something works, but I didn't think of it for this text.
Btw, you made me think of a brick of jelly bears... a catastrophe that can sort of work as a metaphor for some codebases out there ๐
I admit, it wasn't the best metaphor I've made up :D
Btw, my comment comes after an extensive experience on legacy code with 0 automatic tests. I've seen the ups and downs of monoliths, the pros and cons, and one thing is for sure, once you go tests you don't go back. They are not a silver bullet, they just make our life easier.