3 ms·

My JavaScript integration and unit tests do something better; they tell me exactly what features I broke as a result of my refactoring and let me fix things in

My JavaScript integration and unit tests do something better; they tell me exactly what features I broke as a result of my refactoring and let me fix things in the best way possible without regard for the previous structure of the code (which may no longer be relevant anyway; there is usually a good reason why we do refactorings in the first place! It's rarely just about renaming things). I have many stories on the subject but most recently I did a significant refactoring for a JavaScript project (a popular open source library I created) to move from callbacks to async/await and was able to re-use pretty much all of the existing integration test logic with only aesthetic changes (to account for the new async/await API). When I finished the refactoring, I had modified at least 70% of the entire source code of the project and I took it as an opportunity to make significant structural changes to my code to align with the new async/await flow in the most optimal way possible. This kind of big refactoring would have made code highlighting completely redundant and would have prevented me from looking at the problem with a fresh mind and taking into account the new features offered by async/await. It was a very successful refactoring; no new issues were uncovered after the point that I managed to get all the original tests passing again and the code was a lot simpler than before. I think TS has a way of locking down old structures in a way that make it sub-optimal in the long run. Feature-oriented tests are by far the best way to ensure that product quality is maintained after a refactoring IMO.

the_gipsy 7y ago
I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums. In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful. On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.
- cryptica 7y ago
  Well designed tests lock down features not code. That's why I mostly write integration tests. I write unit tests once the project is stable and usually only for parts of the logic that are either very complicated or operationally critical. I try to avoid implementing 'very complicated' modules as much as possible.
  - the_gipsy 7y ago
    Do you mean e2e tests? Because those are the only ones that test features. Integration tests are the biggest offenders of "code lockdown". They don't really test features, yet they have to observe too many implementation details. Unit tests can't really lock down code, or then we shouldn't call those "unit" anymore.

the_gipsy 7y ago

I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums. In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful. On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.

cryptica 7y ago
Well designed tests lock down features not code. That's why I mostly write integration tests. I write unit tests once the project is stable and usually only for parts of the logic that are either very complicated or operationally critical. I try to avoid implementing 'very complicated' modules as much as possible.
- the_gipsy 7y ago
  Do you mean e2e tests? Because those are the only ones that test features. Integration tests are the biggest offenders of "code lockdown". They don't really test features, yet they have to observe too many implementation details. Unit tests can't really lock down code, or then we shouldn't call those "unit" anymore.