4 ms·

Testing with "The Force"

14 points by fogus 17y ago

michael_dorfman 17y ago
Hmmm, seems like pretty dubious advice: So by all means, test your code with the force -- brute force! It's good stuff! Just be careful not to get sloppy, and let the dark side of the testing force prevail. If you think one or two simple test cases covers it, that's taking the easy (and most likely, buggy and incorrect) way out. Unfortunately, the example he gives is the epitome of "sloppy"-- in fact, it represents a total refusal to even attempt to understand the task at hand before beginning coding. Obviously, having a large suite of test cases is an advantage; but it's no substitute for understanding what one is trying to accomplish.
- fogus 17y ago
  Jeff Atwood wants a pile of tests without understanding -- Rich Hickey wants total understanding without tests... Where is the middle ground?
  - michael_dorfman 17y ago
    Well, if you have total understanding you probably don't need tests, but most of us (Knuth excepted, apparently) don't get to that level. So, the middle ground is: understand as much as you can, test as much as you have to.
    - eru 17y ago
      "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth > So, the middle ground is: understand as much as you can, test as much as you have to. Test even what you understand. QuickCheck (http://www.cs.chalmers.se/~rjmh/QuickCheck/ http://www.cs.chalmers.se/~rjmh/QuickCheck/) and friends like SmallCheck and Lazy SmallCheck let you turn specs into tests easily.
Oompa 17y ago
You mean having proper tests is better than having just a few simple ones? Groundbreaking.
steveklabnik 17y ago
The thing is, these aren't even proper tests. Since when do we run Markdown engines over comments that aren't in Markdown to begin with?
- wlievens 17y ago
  And he doesn't have references to test against, so he's probably doing manual inspection. It's a form of testing, though, but definitely not a unit test.
Periodic 17y ago
One fault with TDD that I have heard mentioned is that people tend to write tests and then code only for those tests, ignoring the big picture. Then of course there is the other end of the spectrum where people write the app, then use that as the spec to create tests to avoid breaking things. This is closer to the latter and very sloppy. He's creating a test to fit the data. I feel that tests should embody properties of the perfectly working app, they should be developed almost in isolation, then the code can be modified until it produces the desired output. But all that said, testing with large data sets and random data sets is a very good way to find your edge cases and work towards more robust code.

14 points by fogus 17y ago

Hmmm, seems like pretty dubious advice: So by all means, test your code with the force -- brute force! It's good stuff! Just be careful not to get sloppy, and let the dark side of the testing force prevail. If you think one or two simple test cases covers it, that's taking the easy (and most likely, buggy and incorrect) way out. Unfortunately, the example he gives is the epitome of "sloppy"-- in fact, it represents a total refusal to even attempt to understand the task at hand before beginning coding. Obviously, having a large suite of test cases is an advantage; but it's no substitute for understanding what one is trying to accomplish.

fogus 17y ago
Jeff Atwood wants a pile of tests without understanding -- Rich Hickey wants total understanding without tests... Where is the middle ground?
- michael_dorfman 17y ago
  Well, if you have total understanding you probably don't need tests, but most of us (Knuth excepted, apparently) don't get to that level. So, the middle ground is: understand as much as you can, test as much as you have to.
  - eru 17y ago
    "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth > So, the middle ground is: understand as much as you can, test as much as you have to. Test even what you understand. QuickCheck (http://www.cs.chalmers.se/~rjmh/QuickCheck/ http://www.cs.chalmers.se/~rjmh/QuickCheck/) and friends like SmallCheck and Lazy SmallCheck let you turn specs into tests easily.

Oompa 17y ago

You mean having proper tests is better than having just a few simple ones? Groundbreaking.

steveklabnik 17y ago

The thing is, these aren't even proper tests. Since when do we run Markdown engines over comments that aren't in Markdown to begin with?

wlievens 17y ago
And he doesn't have references to test against, so he's probably doing manual inspection. It's a form of testing, though, but definitely not a unit test.

Periodic 17y ago

One fault with TDD that I have heard mentioned is that people tend to write tests and then code only for those tests, ignoring the big picture. Then of course there is the other end of the spectrum where people write the app, then use that as the spec to create tests to avoid breaking things. This is closer to the latter and very sloppy. He's creating a test to fit the data. I feel that tests should embody properties of the perfectly working app, they should be developed almost in isolation, then the code can be modified until it produces the desired output. But all that said, testing with large data sets and random data sets is a very good way to find your edge cases and work towards more robust code.