In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering April 2013.
April has been a very busy time for me outside of grant work on Devel::Cover.
Apart from other matters, I was fortunate enough to be able to attend the Perl
QA
In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering March 2013.
Sorry for the delay in this report. Most of March and all of April has been a
very busy time for me outside of grant work on Devel::Cover.
This month I
2013/5/2 brian d foy brian.d@gmail.com
In HARNESS_OPTIONS we can set -jN to note we want parallel tests
running, but how can a particular module, which might be buried in the
dependency chain, tell the harness it can't do that?
It seems to me that by the time the tests are running, it's
On Wed, 01 May 2013 22:38:26 +0200, Paul Johnson p...@pjcj.net wrote:
Hours worked:
01.03 7:30
29.03 2:15
Total 9:45
Total hours worked on grant: 257:35
+1, good stuff. :)
--
With regards,
Christian Walde
On Wed, 01 May 2013 22:40:17 +0200, Paul Johnson p...@pjcj.net wrote:
This month I released Devel::Cover 1.02 but, apart from that, almost all
of my work on Devel::Cover was either at or in association with the QA
Hackathon and, as such, I will not be charging it to the grant.
Hours
On Thu, May 02, 2013 at 12:51:06PM -0700, Karen Etheridge wrote:
On Thu, May 02, 2013 at 02:39:13PM -0500, brian d foy wrote:
In HARNESS_OPTIONS we can set -jN to note we want parallel tests
running, but how can a particular module, which might be buried in the
dependency chain, tell the
On Thu, May 2, 2013 at 9:39 PM, brian d foy brian.d@gmail.com wrote:
In HARNESS_OPTIONS we can set -jN to note we want parallel tests
running, but how can a particular module, which might be buried in the
dependency chain, tell the harness it can't do that?
It seems to me that by the time
No, you can't have your tests clean up after themselves. For two
reasons. First, that means you have to scatter house-keeping crap all
over your tests. Second, if you have a test failure you want the
results to be sitting there in the database to help with debugging.
There is another way
Huzzah!
On 5/1/13 3:38 PM, Paul Johnson wrote:
In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering March 2013.
Sorry for the delay in this report. Most of March and all of April has been a
very busy time for me
On Fri, May 03, 2013 at 11:03:28AM -0400, Mark Stosberg wrote:
No, you can't have your tests clean up after themselves. For two
reasons. First, that means you have to scatter house-keeping crap all
over your tests. Second, if you have a test failure you want the
results to be sitting
OK, but you still have to clean out your database before you start each
independent chunk of your test suite, otherwise you start from an
unknown state.
In a lot of cases, this isn't true. This pattern is quite common:
1. Insert entity.
2. Test with entity just inserted.
Since all that
From: Mark Stosberg m...@summersault.com
OK, but you still have to clean out your database before you start each
independent chunk of your test suite, otherwise you start from an
unknown state.
In a lot of cases, this isn't true. This pattern is quite common:
1. Insert entity.
2. Test with
On Friday, May 03, 2013 01:34:35 PM Ovid wrote:
... you'll have to do a lot of work to convince people that starting out
with an effectively random environment is a good way to test code.
Before you dismiss the idea entirely, consider that our real live code running
for real live clients
13 matches
Mail list logo
