Hacker News Reader

Comment by colinramsay | Hacker News Reader

Do you have one resource (book/guide/blogpost) that you think gives a good explanation of how people should be thinking about testing?

View on HN

No, but I should write one. Broadly speaking, I think test coverage in the real world, as practiced by effective programmers, is variable. One must use judgement to decide the appropriate level of test coverage. There are so many factors in making that judgement however that it's hard to distill.

The primary heuristic I look for is "Do I have enough tests that I can be reasonably sure these tests will fail if I break the code". That is the fundamental question! This is different than the RSpec books' approach which is more dogmatic and highly structured (you need to test every function, every entry point, pretty much every single thing). The thing is, the RSpec book approach does work! It works better in fact! It also is a colossal waste of time. I'd write tests like that if I was writing a trading platform for the NYSE, but almost no one does that sort of work.

Since I'm in the midst of writing a book (shameless plug http://exploringelasticsearch.com ) I don't have time to writ e that post unfortunately.

Your post makes me feel like you're missing the point of BDD.

The point of BDD isn't to "stop breaking the code". I think "coders" value "code" too much.

The point of BDD is to build understanding of the problem you're solving by enumerating behavioral ambiguities/edge cases up front, before you've invested time and emotion into a particular code approach.

You're using testable _behavior_ to drive the development of your code. More simply - test first, code second. Having a regression suite is a cool side effect.

Of course, this is just how it's "supposed to work." In real life YMMV. Whether or not you think there's much value in that methodology is another story - but if you are going to dismiss something, you have to dismiss it based on a relevant metric.

Yes, you have just regurgitated the rhetoric. But there are a lot of problems which the enumeration you describe is simply the wrong way to build understanding.

See http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... for an interesting example.

I agree! I like the idea of BDD. I disagree with the rspec book in degree, it goes overboard, too many tests for not enough return.

I think Ryan Bates "How I test" screencast is a great example. It's specific to rails but I've used this approach on web applications in a few different frameworks. http://railscasts.com/episodes/275-how-i-test?view=asciicast

Basically, test the heck out of your domain model layer, and then do full stack acceptance tests above that to simulate the user using the app. If it's a web app use something like Capybara, if its a terminal app or some other interface, simulate that appropriately with some other kind of integration test.

Perfect Software and Other Illusions About Testing by Jerry Weinberg might be a nice start. Or anything by Weinberg

http://www.geraldmweinberg.com/Site/Perfect_Software.html

Depends what level of testing, but the Cucumber Book gives great examples as to how to write Acceptance Tests for customers:

http://pragprog.com/book/hwcuc/the-cucumber-book

The Rspec Book. Even though it advocates Cucumber (I kind of ignored that part), it really explains how to think about tests. How to approach unit tests, integration tests, and testing behavior not implementation. I don't write Ruby code or Ruby Specs, and I found the code and the book completely applicable to PHP and JavaScript testing.

http://www.amazon.com/The-RSpec-Book-Behaviour-Development/d...

I could be wrong, but the op was asking for a book recommendation beyond the Rspec book, because the root message of this thread says: "The Rspec book is a load of crap."

Reply on news.ycombinator.com