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
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:
* http
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. I
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 no
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
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 als
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. Th
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 wha
# 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 base
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 cor
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
(understa
11 matches
Mail list logo
