How would you make a blog with a TDD approach?

Question

I'm considering remaking my blog(currently in PHP, but <100 lines of non-layout code) in Ruby on Rails just for the fun of it. I want to make another project in Rails, but I should learn Rails(more than hello world) before I go to try to create a full project.

Another thing I want to do while remaking my blog is to at least figure out what TDD is all about. So how would you go about taking a Test Driven approach to the creation of a blog? What tests would you write? How would you begin?

Everytime I visualize writing a blog it'd end up needing a million tests for a single component to fully test it. How do I avoid writing too many tests?

Also, I am making this community wiki because I intend for this to basically be made into a mini tutorial/knowledge base...

I went ahead and put a bounty on this question so maybe I can actually get a good answer to this..

Answer 1

TDD is more about design then it is about testing. A lot of people miss this and will end up practicing something which doesn't quite feel like TDD. With TDD, you are writing a test to drive a change in your code. You shouldn't need to worry about writing too many tests, because you should only have a test to write if there is more production code to write (and therefore, more code to test). Again, TDD is NOT about just writing lots of tests for your code, but you will end up with lots of tests and hence, you will have a very powerful suite of tests to give you feedback as your code grows and changes.

Rather then talking about how to test drive the development of some particular piece of software, I'd recommend you read up and learn how to practice TDD and figure out, as you said, what its all about. One good book to consider is: Growing Object Oriented Software, Guided by Tests. The book uses Java, but it is a great real-life application of using TDD to build a fairly complex piece of software.

There's a lot to TDD, and I would recommend really digging in to a few good sources if you want to learn and try to practice it because there is more than can be brought up in answers to this question.

Answer 2

Start out by writing Cucumber features to provide an "outside-in" coverage. These should be able to test the large majority of your functionality by themselves. Very easy to write. A blog doesn't have that many tests, after-all it's just posts and comments, right? Have a look at my blorgh application which is a Rails app developed using Cucumber.

Answer 3

Interesting, this is exactly what I started a couple of days ago. I am using RSpec and Cucumber. I started by writing a couple of specs for Article and Comment models. When they all went green I wrote Cucumber tests to implement views, controllers etc.

This works really well for me but I guess starting with Cucumber is good too as many seem to like this approach.

In case you have only few knowledge of RSpec and Cucumber I highly recommend Railscasts:

• Beginning with Cucumber
• More on Cucumber
• Testing Controllers with RSpec
• RSpec Matchers & Macros

I also liked the Peepcode screencasts but unlike the railscasts they cost 9$ each.

Answer 4

Take a look at the stakeholders, and what they want to accomplish. It is important to start there, because it allows you to prioritize correctly (i.e. not on the most interesting technical part, but on the part with the most business value). The developer is a stakeholder, and reducing his fears (of not being able to build something) is a valid goal.

The thinking about design is written down in tests. Start with the stakeholders end-goals, work from there backwards to the beginning (Time-inversion). That ensures that you concentrate on what, and less on how. Interaction between objects is more important to get right than object attributes.

See:

• http://www.robvens.nl/en/articles/computers/29-time-inversion-pattern
• http://www.robvens.nl/en/articles/computers/28-active-passive-pattern

Answer 5

I have a similar opinion to Pete, its more about design.

Jumping on it before having looked at quality information is likely not to give you the results. It'd likely just make you think: these tests feel like a pain. This is a realization that there are design issues, but it won't tell you how to improve it.

You said "currently in PHP, but <100 lines of non-layout code", if that's the case there is probably a handful of features. If you focus on the actual features needed there should also be few tests / higher than the amount of features of course, but as long as those are the right unit tests the number shouldn't explode - check this video.