Short answer: Think about what you want your forum code to do, then test that it does it :-)

Slightly more useful answer...

Before you write any code think about the requirement you're trying to meet, write a test for that requirement, then write some code to make the test pass.

For example, if your forum consists of a number of named boards you need to create them - so write a test for board creation:

isa_ok( Forum::Board->new(name => 'testboard'), 'Forum::Board' );

[download]

Run the test. It fails. Now go write the code to make a board. You know when you've finished because the test will pass.

Next you might need to get the name of an existing board, so write a test:

is( Forum::Board->new(name => 'testboard')->name, 'testboard');

[download]

Write code until test passes.

Repeat the test/code cycle until all the module does all you want it to do.

Never write code without a failing test. That way you build up your test suite as you go and end up with very good test coverage of your codebase.

If something looks too complicated to test break it down into smaller chunks. For example, you have a code that takes various parameters and passes them to a template to display to the user.

At the simplest level you could pass known parameters and look at the output and compare it with the output you want. Either as an exact string match, or by checking that the important bits are in the output string with a set of regexps. Gnarly.

However, you could also separate it into two different tests:

  1. Am I generating the correct parameters for the template
  2. Is the template generating the correct output from the parameters

Instead of testing both together, test each individually.

  1. Use a mock object for the template to make sure that the correct parameters are passed.
  2. Pass known parameters to the template to make sure that the correct output is produced.

This way you ensure that your unit tests really are unit tests - and you're only testing one component at a time.

I find that thinking "I can't test that" is usually a code smell. It indicates that there is a problem with my code and something is too tightly coupled to something else.

When you get to doing acceptance testing it's probably simplest to just drive the application with something like WWW::Mechanize. You might find Unit Testing Generated HTML of interest too.

Hopefully this makes some vague sort of sense :-)

In reply to Re: Test Suite for a forum? by adrianh
in thread Test Suite for a forum? by BUU

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.