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?
返信削除