I have certainly experienced (and written) frontend presentation and form management code, that would benefit from automated testing (Selenium as a rule) or unit testing if that's the preferred term (as the tests are defined in little bits, of targeted testing so that if it breaks - i.e. an expectation is not met, it's easy to find the code to blame.
But yes, that is the only code I would generally like to see client side really.
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.
I have certainly experienced (and written) frontend presentation and form management code, that would benefit from automated testing (Selenium as a rule) or unit testing if that's the preferred term (as the tests are defined in little bits, of targeted testing so that if it breaks - i.e. an expectation is not met, it's easy to find the code to blame.
But yes, that is the only code I would generally like to see client side really.
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).