30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
For those worrying about the potential explosion of tests in trying to cover lots (effectively infinite) of edge cases and bad inputs, there is some hope from at least a couple of sources:
James O Coplien's seminal paper: rbcs-us.com/documents/Why-Most-Uni... which takes a slightly acerbic but very practical and well thought out view of where and how to test.
The insight of your fellow dev.to member, dev.to/roesslerj/ and others in the testing community, who understand this in excruciating detail and want to help :)
I wonder - did my article really leave that feeling, being worried about the amount of unit tests needed?
If so, I did a terrible job and apologize.
My intention was to point out that automated unit tests are not the solution (though they might be one of several tools), but deeper understanding of the problem domain (I think in that case I follow Jim Copliens argumentation pretty much).
Also, please consider reading the article on automated self-testing I wrote and linked in the post (also on dev.to: dev.to/pesse/strongholds-of-confid...)
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
My apologies too, I wasn't reacting so much to your excellent article, as wanting to provide more information on the meaning of valuable tests, I guess I used the wrong phrase to introduce them :)
Thanks for your reply. As newbie-writer feedback is very important for me and I was really concerned.
Also thanks for the recommendation of roesslerj - didn't know his work yet.
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.
For those worrying about the potential explosion of tests in trying to cover lots (effectively infinite) of edge cases and bad inputs, there is some hope from at least a couple of sources:
James O Coplien's seminal paper: rbcs-us.com/documents/Why-Most-Uni... which takes a slightly acerbic but very practical and well thought out view of where and how to test.
The insight of your fellow dev.to member, dev.to/roesslerj/ and others in the testing community, who understand this in excruciating detail and want to help :)
I wonder - did my article really leave that feeling, being worried about the amount of unit tests needed?
If so, I did a terrible job and apologize.
My intention was to point out that automated unit tests are not the solution (though they might be one of several tools), but deeper understanding of the problem domain (I think in that case I follow Jim Copliens argumentation pretty much).
Also, please consider reading the article on automated self-testing I wrote and linked in the post (also on dev.to: dev.to/pesse/strongholds-of-confid...)
Cheers,
A very concerned Pesse
My apologies too, I wasn't reacting so much to your excellent article, as wanting to provide more information on the meaning of valuable tests, I guess I used the wrong phrase to introduce them :)
Thanks for your reply. As newbie-writer feedback is very important for me and I was really concerned.
Also thanks for the recommendation of roesslerj - didn't know his work yet.