in reply to Inheriting Bullsh!t

Your explanation sounds very straightforward to me where it ends at this point. I would imagine you want to confirm that when certain different lists are presented on the inputs, you get sane SQL as the output.

Start with the simplest possible input list, and confirm that the correct SQL comes out, using tests of course. Start to make your lists more complex and confirm that as you do that, your queries keep pace. Do that as far as you can.

When you start to run out of steam there, try the web interface controls and see what other combinations and permutations you can think of for the inputs, and make sure that they produce the right SQL.

You might be able to use SQL::Abstract to reduce the complexity of some of this code -- but I would hold off doing that until you're re-writing this code based on the work you've done building the test suite.

Sounds like fun -- good luck!

Alex / talexb / Toronto

Team website: Forex Chart Monkey, Forex Technical Analysis and Pickpocket Prevention

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Replies are listed 'Best First'.
Re^2: Inheriting Bullsh!t
by pemungkah (Priest) on Dec 03, 2009 at 22:12 UTC
    And you should note that if this works, you've started writing your test suite! Go ahead and use Test::More/etc. to write this code; you can then keep checking in the tests as you make more of them to figure out what the code does.

    You can simulate the Web stuff by sending URLs to your backend server - even if there's a lot of Javascript in the front end, you can just look at the access log to see what URLs were visited and visit those directly with WWW::Mechanize.

    Finally, make sure that the code is checked into a source code control system - whatever one you're comfortable with if it's not already in source control. You want the option to explore the code and back out changes that turn out to be wrong.