Yes, but these aren't technically unit tests. When I've done similar things though, I tend to struggle with changes in the code as a part of the requirements breaking my tests, which is kind of my exaggerated point here, that tests are most valuable when you can modify the code and drive it forward without breaking your tests ...
However, I wrote this article series mostly to make people think, which is why I ended it with a Lada is better than a Ferrari :D
To be honest, unit tests should only really focus on stable requirements or code upon which other code depends. They are a cementing strategy to monitor, and implicitly demand stability in the things tested. Perforce that is not ideal for code which is changing a lot (being developed) unless, adding the overhead of evolving tests alongside the developing code is a choice invested in (TDD would argue writing the test first even, but I've not found many investing in the cost of TDD). Myself, am coding a pile of unit tests on core code, on a project as its large enough that new developments risk breaking things unintentionally (or better said that ever present risk has crossed a threshold of tolerance and so investing in cementing tests has reached the top of the to-do list).
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.
Yes, but these aren't technically unit tests. When I've done similar things though, I tend to struggle with changes in the code as a part of the requirements breaking my tests, which is kind of my exaggerated point here, that tests are most valuable when you can modify the code and drive it forward without breaking your tests ...
However, I wrote this article series mostly to make people think, which is why I ended it with a Lada is better than a Ferrari :D
To be honest, unit tests should only really focus on stable requirements or code upon which other code depends. They are a cementing strategy to monitor, and implicitly demand stability in the things tested. Perforce that is not ideal for code which is changing a lot (being developed) unless, adding the overhead of evolving tests alongside the developing code is a choice invested in (TDD would argue writing the test first even, but I've not found many investing in the cost of TDD). Myself, am coding a pile of unit tests on core code, on a project as its large enough that new developments risk breaking things unintentionally (or better said that ever present risk has crossed a threshold of tolerance and so investing in cementing tests has reached the top of the to-do list).