On 2 Mar 2007, at 22:53, James E Keenan wrote:
Adrian Howard wrote:
[snip]
Adrian: How about posting this part on http://perl-qa.yi.org/
index.php/Main_Page?
[snip]
ObItsAWiki :-)
Adrian
On 1 Mar 2007, at 16:42, Andrew Gianni wrote:
[snip]
In this situation, we would still like something in place to ensure
that
altering the construction of the business rules doesn't cause
regression in
the application, but we can't (or I'd certainly rather not) simply
write
unit tests for.
Adrian Howard wrote:
[snip]
Adrian: How about posting this part on
http://perl-qa.yi.org/index.php/Main_Page?
For more general testing discussions I'd recommend joining all of:
* [EMAIL PROTECTED]
* [EMAIL PROTECTED]
* [EMAIL PROTECTED]
You also might want to look at all or some of:
*
We're starting to write some rather complex business applications that
include a lot of business rules and I've come up against a bit of a
conundrum: how to best test things that aren't unit-testable. Let me
explain.
We've gotten rather efficient at writing unit tests, using Devel::Cover
On 1 Mar 2007, at 16:42, Andrew Gianni wrote:
Any insight appreciated. Recommendations on good books on general
testing
philosophy would also be helpful (I've already got the developer's
notebook).
It sounds as if you have two distinct things to test. You have a
rules engine that has to
# from Andrew Gianni
# on Thursday 01 March 2007 08:42 am:
However, our business rules
have gotten complicated enough that we are no longer writing them that
way explicitly in the code. In the last application we built, we put
the rules in a database and the appropriate ones were pulled based
On 3/1/07 12:18 PM, Andy Armstrong [EMAIL PROTECTED] wrote:
To test the rules you could maybe extend the rule notation to allow
assertions to be expressed as part of the rule set and write a test
harness that uses your (now proved) rules engine to test the assertions.
That's sort of what I
On 1 Mar 2007, at 18:15, Andrew Gianni wrote:
To test the rules you could maybe extend the rule notation to allow
assertions to be expressed as part of the rule set and write a test
harness that uses your (now proved) rules engine to test the
assertions.
That's sort of what I was thinking.
On Thursday 01 March 2007 10:36, Andy Armstrong wrote:
In addition to the benefits of test coverage you're being persuaded
to decouple components from one another so they can be used both for
testing and in the application - which is in general a good thing.
If you get it right it'll also be
On 3/1/07 1:42 PM, chromatic [EMAIL PROTECTED] wrote:
On Thursday 01 March 2007 10:36, Andy Armstrong wrote:
If you get it right it'll also be a great help to the people writing
the rules. You can give them a tool which allows them to start with
an assertion and work backwards to a rule
On 3/1/07 1:05 PM, Eric Wilhelm [EMAIL PROTECTED] wrote:
although it's taken care of by a module
that we can assume is fully tested (details will be forthcoming at
some point, methinks).
I would like to see that. Please keep us posted.
Will do, it'll be on CPAN, although I'm not the
11 matches
Mail list logo
