I wanted an easier way to create test fixtures with DBIx::Class, so I wrote it.
I've written about it here:
http://blogs.perl.org/users/ovid/2014/02/easy-fixtures-with-dbix-class.html
Since this is the QA group, I feel that you might appreciate this more than
most. Bug reports and
--- Ovid <[EMAIL PROTECTED]> wrote:
> Later, the 'Our::Test::Database' has a DESTROY method which drops the
> database. At the beginning and end of every .t file, the database is
> created from scratch and destroyed.
I forgot to mention something very important if you use this technique.
We cac
On 2/13/07, Kirrily Robert <[EMAIL PROTECTED]> wrote:
can someone explain it to me *in a perlish way*.
I think of fixtures as code that helps make testing data driven. I haven't
used Test::Class (though I probably should sometime), but instead, I
refactor my unit tests into t
) so you can measure the luminosity and verify
that it is within spec.
So, the fixture gives you the surrounding environment (and/or related
inputs, overrides CORE::GLOBAL::time and whatever), then your test
just
involves one chunk of code and the direct inputs to it. e.g. You
might
have seve
ish? Wanna make something of it ;-)
would anyone else be able to
provide confirm that I'm making sense in the following
Test::Harness/Test::More style example:
1. Assume a test file t/foo.t
2. Assume a directory t/data (or t/fixtures if you will -- I just call
it data in my own tests).
3.
--- Thomas Klausner <[EMAIL PROTECTED]> wrote:
> I guess with some more fiddling the END-block could be made smart
> enough
> to only tear down stuff that was actually set up, but it worked for
> me...
If you're using a DB, you can use transactions (AutoCommit => 0) and
rollback at the end.
If
Hi!
On Wed, Feb 14, 2007 at 09:46:19AM +1100, Kirrily Robert wrote:
> example used Test::Class's setup/teardown; would anyone else be able
> to
> provide confirm that I'm making sense in the following
> Test::Harness/Test::More style example:
I had to do something similar just yesterday. I wrote
--- Kirrily Robert <[EMAIL PROTECTED]> wrote:
> 2. Assume a directory t/data (or t/fixtures if you will -- I just
> call
> it data in my own tests).
> 3. Create a file t/data/foo.yml (or whatever data format) containing
> the
> data needed by the tests in foo.t
> 4. At t
Ruby has a nice description at
http://manuals.rubyonrails.com/read/chapter/26
To quote
"Fixtures is a fancy word for ‘sample data’. Fixtures allow you to populate
your testing database with predefined data before your tests run."
Think about how something like Test::MockDBI's
est::More style example:
1. Assume a test file t/foo.t
2. Assume a directory t/data (or t/fixtures if you will -- I just call
it data in my own tests).
3. Create a file t/data/foo.yml (or whatever data format) containing the
data needed by the tests in foo.t
4. At the beginning of foo.t, load da
On 2/12/07, Kirrily Robert <[EMAIL PROTECTED]> wrote:
Does anyone here understand "fixtures" as a testing concept, and could
they please explain it to me in a Perlish way?
In terms of etymology only, it was explained to me that the term
"fixture" comes from th
# from Ovid
# on Tuesday 13 February 2007 01:16 am:
>--- Kirrily Robert <[EMAIL PROTECTED]> wrote:
>> Does anyone here understand "fixtures" as a testing concept, and
>> could they please explain it to me in a Perlish way?
>>
>> At least half of what I&#
[EMAIL PROTECTED] wrote:
> On Tue, Feb 13, 2007 at 09:20:29AM -0800, chromatic wrote:
>> On Tuesday 13 February 2007 08:24, Ovid wrote:
>>
>>> Really? :)
>>>
>>> java.lang.NullPointerException
>> Oh please, everyone knows Java doesn't have pointers!
>
> Of course it does. They may not be accessibl
On Tue, Feb 13, 2007 at 09:20:29AM -0800, chromatic wrote:
>On Tuesday 13 February 2007 08:24, Ovid wrote:
>
>> Really? :)
>>
>> java.lang.NullPointerException
>
>Oh please, everyone knows Java doesn't have pointers!
Of course it does. They may not be accessible to the programmer
due to the desig
On Tuesday 13 February 2007 08:24, Ovid wrote:
> Really? :)
>
> java.lang.NullPointerException
Oh please, everyone knows Java doesn't have pointers!
-- c
OT - there are a lot of definitions of fixtures. The best I've found
is "stuff tests share", which is exactly what Skud said.
--- Matisse Enzer <[EMAIL PROTECTED]> wrote:
> Typically the programmers provide a "Fixture" for each category of
> testing and the non-programers edit a wiki page to add rows to a
> table. Each row in the table on the wiki page is interpreted as a
> assertion and when you click the "test" b
On Feb 12, 2007, at 10:35 PM, Kirrily Robert wrote:
Does anyone here understand "fixtures" as a testing concept, and could
they please explain it to me in a Perlish way?
One definition of a "fixture" comes from the Fitnesse system which is
a framework for collabo
--- Kirrily Robert <[EMAIL PROTECTED]> wrote:
> Does anyone here understand "fixtures" as a testing concept, and could
> they please explain it to me in a Perlish way?
>
> At least half of what I've heard described is what I usually achieve
> with a t/
Does anyone here understand "fixtures" as a testing concept, and could
they please explain it to me in a Perlish way?
At least half of what I've heard described is what I usually achieve
with a t/data/ directory, and another half is what I'd do by writing a
specialized
19 matches
Mail list logo
