On 3/1/07, David Golden [EMAIL PROTECTED] wrote:
I've had some requests for a mechanism for module authors to indicate
whether or not they want to be copied on module test emails generated
by CPAN::Reporter (particularly for passing reports). This seems like
the kind of thing that should go in
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
Hi,
I'm trying to get MakeMaker to create a Makefile for me which should
do the following, but I fail in one part:
* Put my Perl modules to $prefix/sbin
* Put my Perl script to $prefix/sbin as well
* Put some binary file to $prefix/bin
The last step doesn't work since the binary files
Florian Scharinger wrote:
Hi,
I'm trying to get MakeMaker to create a Makefile for me which should do
the following, but I fail in one part:
* Put my Perl modules to $prefix/sbin
Uhh, Perl modules in sbin? You sure?
* Put my Perl script to $prefix/sbin as well
* Put some binary
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
Brad Lhotsky wrote:
I'm in the process of implementing a large scale central syslog
architecture based on syslog-ng and POE. syslog-ng buys me compliance
while I finish building my custom correlation engine with POE.
If you're trying to implement a syslog server in POE, did you take a
look
Michael G Schwern wrote:
Yuval Kogman wrote:
Likewise with ref in boolean context, I almost never want the object
to be able to lie to me.
But if it has to work hard to lie, then does it matter?
Yeah, I'm with Yuval here. There seem to be a cold war going on here wrt
identifying an object.
chromatic wrote:
On Monday 26 February 2007 13:50, Michael G Schwern wrote:
But what if isa() is broken or has side effects, hmm?
That's not the caller's problem. Fix the broken code. Don't break more code
trying to work around bugs.
I think the problem he's refering to is that if the
Adam Kennedy wrote:
IT SHOULD NOT BE THIS COMPLICATED TO IDENTIFY THE HERITAGE OF AN OBJECT!
use Params::Util '_INSTANCE';
if ( _INSTANCE($obj, 'Whatever') ) {
}
Oh good, depend on another module to implement a basic language feature.
(I appreciate your suggestion but I'm LAMENTING
Yuval Kogman wrote:
BTW, pure perl blessed() will work:
sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
sub blessed ($) {
local($@, $SIG{__DIE__}, $SIG{__WARN__});
length(ref($_[0]))
? eval { $_[0]-a_sub_not_likely_to_be_here }
Yuval Kogman wrote:
On Sun, Feb 25, 2007 at 22:34:15 -0800, chromatic wrote:
Why not, I already have half of the other stuff in UNIVERSAL
Just don't tell Adam.
As much as I dislike UNIVERSAL::, I'd FAR prefer to have it all
maintained by one person.
That way I can submit my
chromatic wrote:
On Monday 26 February 2007 06:35, Christopher H. Laco wrote:
Or me. I have a personal hate relationship with MockObject in this way.
I love MockObject. I hate getting warnings about 3 party modules use of
can in my test suite.
Ideally those third parties would fix their
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can directly.
That's the only case I can think of too.
-- c
chromatic wrote:
On Thursday 01 March 2007 17:46, Adam Kennedy wrote:
Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to
remember that at one point it was considered the only valid use of
UNVERSAL::can directly.
That's the only case I can think of too.
Hmm, that's a clever
20 matches
Mail list logo
