# 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'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 Test::Builder-based module. > >A test fixture establishes a "known state" of a system. For example, > when running with Test::Class, you can use "setup" and "teardown" > methods which run before and after every test to load test data in a > database, set up temp files, or do anything necessary to start a > known, stable state and later do transaction rollbacks, clean up temp > files and so on.
Good description, but I think "teardown" is (at least conceptually) part of "setup". How about, "a thing into which the item under test gets inserted"? The c2 wiki (http://c2.com/cgi/wiki?TestFixture) has it as analogous to an electronics test fixture. They should probably include "light fixture" as a very simple metaphor. If you're testing electric lamps (non-engineers usually call them "light bulbs"), you screw them into a test fixture, plug it in, and flip the switch. This emulates the production environment, but with known variables (input voltage, surface reflectance, etc) 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 several fixtures, each of which creates an object with a known set of attributes, then the tests call a method call on that object with various parameters. --Eric -- Speak softly and carry a big carrot. --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
