Live data from Hacker News

Ask HN: How do people really test their code?

news.ycombinator.com

21–29 of 29 posts

Re: Ask HN: How do people really test their code?

#21
post #17

Earlier quoted context omitted.

Could you recommend some resources for learning BDD?

Sure. Now that I'm not on my phone, it's much easier to grab some links. Here's the original work on the subject, by Dan North: http://blog.dannorth.net/introducing-bdd/ A little Rails specific, but this post by Sarah Mei is pretty awesome: http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/ These two Railscasts on Cucumber are good: http://railscasts.com/episodes/155-beginning-with-cucumber http://railscasts.com…

Adding on to your comment, a friend let me read through a beta copy of The Rspec Book last year. At the time, only the first couple chapters were written and it was lacking a lot of content. It was a great resource though, and I would highly recommend it. The final release is due "Soon", and ordering it now gives you access to the current revision of the Beta, which I hear is complete sans-editing. I'm holding out until I can buy a paper copy.

http://www.pragprog.com/titles/achbd/the-rspec-book

Your links to the RailsCasts screencasts are great also. PeepCode also has their Cucumber Screencast that is a little more detailed than RailsCasts.

http://peepcode.com/products/cucumber

These are all Ruby or Rails specific. Cucumber itself is a DSL to be used along with another language, and there are projects underway to implement Cucumber or Cucumber-like frameworks for other languages like Python, Java and .NET

Re: Ask HN: How do people really test their code?

#22
Personally I use a triplet of tests.

1) The first test I right is a functional end to end test that assumes the application is deployed and running with all configuration in place. That means there is a database and all the other parts necessary to run the application. The test follows BDD format (Given ... when ... then). Its purpose is to cross the bridge between high level functional requirement (I want X) to an executable spec for the aspects of that.

2) I then develop a series of unit tests. These don't require a database or even the file system, they are purely in the language of the application. I use a mocking framework to isolate to units and TDD out all the aspects.

3) Finally I write a performance test. A preloaded set of known data is inserted into an environment looks very similar to production. Any additional specialist data for the individual test is then loaded on top and the test is run and asserted against an expected maximum time.

The combination of the three is working OK for me but there are still gaps. Its hard to get the automated performance testing right as there are so many types of tests you actually want to run which are very hard to automatically verify.

That is how I do it IRL.

Re: Ask HN: How do people really test their code?

#23

Rough rule of thumb that works wonders: Write/modify code. Run program and/or ensure that codepath is executed. Did it do what you intended? If yes, figure out what's wrong about it, fix it, retry. If no, move on to next item on your agenda. (Possibly first doing a quick refactor to improve readability, etc.)

If you refactor you should always retest. I've lost track of the number of times things have been broken by someone tweaking things to make them better.

Re: Ask HN: How do people really test their code?

#24

Rough rule of thumb that works wonders: Write/modify code. Run program and/or ensure that codepath is executed. Did it do what you intended? If yes, figure out what's wrong about it, fix it, retry. If no, move on to next item on your agenda. (Possibly first doing a quick refactor to improve readability, etc.)

If you refactor you should always retest. I've lost track of the number of times things have been broken by someone tweaking things to make them better.

The flip side of this is that you can do deep refactoring with more confidence if you have thorough test coverage (and/or a smart type system).

Re: Ask HN: How do people really test their code?

#25
post #21

Earlier quoted context omitted.

Sure. Now that I'm not on my phone, it's much easier to grab some links. Here's the original work on the subject, by Dan North: http://blog.dannorth.net/introducing-bdd/ A little Rails specific, but this post by Sarah Mei is pretty awesome: http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/ These two Railscasts on Cucumber are good: http://railscasts.com/episodes/155-beginning-with-cucumber http://railscasts.com…

Adding on to your comment, a friend let me read through a beta copy of The Rspec Book last year. At the time, only the first couple chapters were written and it was lacking a lot of content. It was a great resource though, and I would highly recommend it. The final release is due "Soon", and ordering it now gives you access to the current revision of the Beta, which I hear is complete sans-editing. I'm holding out un…

Thanks. I almost linked to the RSpec Book, but since I haven't read it myself, I didn't feel comfortable endorsing it. Good to know it's shaping up! Maybe I'll have to pick up a copy.

Re: Ask HN: How do people really test their code?

#26
For web applications? Watir. Unit tests are great and all, but not that useful compared to high-level functional tests that tests the stuff users are actually interested in doing. With limited time and limited resources, write Watir tests first.

Test #1: Sign up. Did it work? Were all parameters set correctly? Test #2: Log in. Did it work? Are you logged in as the correct user? Test #3: Something that touches your most important business logic. Can the logged in user add an item to her shopping cart? Post in her blog?

Just a hundred tests like that gets you a long way, and doesn't take that long to write.

Re: Ask HN: How do people really test their code?

#29
It very much depends on what you are doing. How many errors per KLOC can you deal with? A website isn't going to have the same requirements that NASA does. On the one end, try acceptance testing and user testing. Its cheap and fast. On the other end, provably bug free code is difficult (not quite impossible http://www.ece.cmu.edu/~koopman/ballista/index.html) but requires better documentation than anyone should ever write.
Post reply on HN