"Unit testing does not improve quality just by catching errors at the unit level. And, integration testing does not improve quality just by catching errors at the integration level. The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection."
These days people are trying to divine the purpose of microtesting from the capabilities of the prevalent tooling alone, concluding it's about "correctness"—the original intent from 26 years ago has been all but lost.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
@natescode tests do not validate implementation details, tests validare behaviour, which is just what you want to avoid changing when refactoring.
By the ctrl+f thingy seems that the testing concept is not so clear and you still thing that refactor is just "changing code".
If you added a third parameter to a function chances are that the best option really was to split it instead or if you run against the clock simply set it as optional instead and mark it to refactor in the future 🤷🏻♀️
The reason for tests is not to add "correctness" bit to add confidence in the code which is something that types alone can't provide.
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.
If they are doing that then they are a waste of time.
Microtests cannot "verify correctness". They are there to detect unwanted change in system behaviour which is exactly what you need when you refactor.
In 2014 James O. Coplien published Why Most Unit Testing is Waste (part 2). Michael Feathers responded with one of his earlier articles The Flawed Theory Behind Unit Testing (2008).
"Unit testing does not improve quality just by catching errors at the unit level. And, integration testing does not improve quality just by catching errors at the integration level. The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection."
In 1996 Extreme Programming (Kent Beck et al.) used unit tests as a design/development feedback tool. This formed the basis of the Classical/Inside Out/Bottom Up/Detroit/Chicago school of unit testing in 1999. The emergence of mocking libraries gave rise to the Mockist/Outside In/Top Down/London school of unit testing in 2000 shifting the focus towards "correctness".
These days people are trying to divine the purpose of microtesting from the capabilities of the prevalent tooling alone, concluding it's about "correctness"—the original intent from 26 years ago has been all but lost.
@natescode tests do not validate implementation details, tests validare behaviour, which is just what you want to avoid changing when refactoring.
By the ctrl+f thingy seems that the testing concept is not so clear and you still thing that refactor is just "changing code".
If you added a third parameter to a function chances are that the best option really was to split it instead or if you run against the clock simply set it as optional instead and mark it to refactor in the future 🤷🏻♀️
The reason for tests is not to add "correctness" bit to add confidence in the code which is something that types alone can't provide.