I strive to use a risk assessment to decide what to test. I'll assume the following definition:
risk = chance * effect
For instance, if you have a trivial regex you may not feel the need to test it. But sometimes getting it wrong can really screw things up.
I had this hobby project that works with musical keys for follow-up suggestions while djing. I wrote an import to take data from the djing application including the key I needed. I made a mistake in a regex causing some tracks to be assigned the wrong key.
Both chance and effect were high in this case:
I know that often enough regex is not a first-time-right affair, at least for me
Assigning the wrong key to a track is detrimental for this application.
On top of that the spec consisted of 24 discrete cases. In retrospect, writing out the spec to test that code should've been a no brainer.
I found it rather unsettling to discover that bug. I'm glad I learned this on my hobby project, but I realized I could've made the same mistake if it wasn't.
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 strive to use a risk assessment to decide what to test. I'll assume the following definition:
risk = chance * effectFor instance, if you have a trivial regex you may not feel the need to test it. But sometimes getting it wrong can really screw things up.
I had this hobby project that works with musical keys for follow-up suggestions while djing. I wrote an import to take data from the djing application including the key I needed. I made a mistake in a regex causing some tracks to be assigned the wrong key.
Both chance and effect were high in this case:
On top of that the spec consisted of 24 discrete cases. In retrospect, writing out the spec to test that code should've been a no brainer.
I found it rather unsettling to discover that bug. I'm glad I learned this on my hobby project, but I realized I could've made the same mistake if it wasn't.