Hey Misko great post, and I enjoy the blog! Is it too presumptuous of me to suggest another category of bugs? How about promiscuous references, where you accidentally share a reference and some where else someone modifies your state.
Does the "wiring" category include bugs that result from wrong assumptions about libraries or frameworks you are using? This (along with failing to take into account some of the things that can happen) is perhaps my most common kind of bug.
I too think there's a category missing: accidental [1] bugs.
Race conditions, timing issues, crashes, performance problems, for example. Things that aren't essential to your program, but affect it deeply when they don't work.
I didn't manage to classify them into either of the other buckets, but maybe you have more thoughts on this?
Thanks, - Kim
[1] In the sense of the second definition here: http://en.wiktionary.org/wiki/accidental
"Unit-test are focused on a single CUT (class-under-test)" - IMHO it's wrong. Unit tests is about testing a unit. It doesn't need to be one class. Do you have any resource related to mentioned statement?
Hey Misko great post, and I enjoy the blog! Is it too presumptuous of me to suggest another category of bugs? How about promiscuous references, where you accidentally share a reference and some where else someone modifies your state.
ВідповістиВидалитиDoes the "wiring" category include bugs that result from wrong assumptions about libraries or frameworks you are using? This (along with failing to take into account some of the things that can happen) is perhaps my most common kind of bug.
ВідповістиВидалитиCan you temll me how to figure out the number of bugs?
ВідповістиВидалитиAnyway, I think this is a very good post... :)
> they don't really understand testable-code
ВідповістиВидалитиI'd love to see a blog post with a top-10 (or top-5, or top-3, whatever) guidelines to follow to produce testable code.
I realize many of your blog posts touch on various aspects of this, but it'd be helpful to see a snapshot of the most important points.
Just do opposite of this:
ВідповістиВидалитиhttp://misko.hevery.com/2008/07/24/how-to-write-3v1l-untestable-code/
I too think there's a category missing: accidental [1] bugs.
ВідповістиВидалитиRace conditions, timing issues, crashes, performance problems, for example. Things that aren't essential to your program, but affect it deeply when they don't work.
I didn't manage to classify them into either of the other buckets, but maybe you have more thoughts on this?
Thanks,
- Kim
[1] In the sense of the second definition here: http://en.wiktionary.org/wiki/accidental
"Unit-test are focused on a single CUT (class-under-test)" - IMHO it's wrong. Unit tests is about testing a unit. It doesn't need to be one class. Do you have any resource related to mentioned statement?
ВідповістиВидалити