at this point the biggest help would be for people to use the code [1] and submit issues/patches when they run into something. However, understand that the interface is a little wobbly. I do plan on committing to a final release before pycon (not committing to the features in that release, just to an "interface that will be supported")
[1] the first generation of fixture (testtools.fixtures) is used internally at my company on a large test suite for ETL processing (~240 tests) but I haven't had the opportunity to port that suite to use the new fixture module yet. On 1/30/07, Carlo Sogono <[EMAIL PROTECTED]> wrote: > > Kumar, good stuff. I'm going to look into fixture within the next few > weeks and see how I can help out. I wouldn't consider myself an advanced > Python developer though... > > Would be nice to go to PyCon but I live down under in Sydney =( but > doubt my employer would pay for me to fly halfway around the world. I > work for a hosting company and all our web applications are written in > Python (website, control panels, internal admin system, credit card > payment interfaces for merchants, etc). At the moment we're slowly > moving towards test-driven development so I'm really keen on getting a > proper test framework going. Let me know if you need any sort of help > with fixture... > > Cheers, > Carlo > > PS. Does anyone want to sponsor me a plane ticket to PyCon? =D > > > Kumar McMillan wrote: > > This isn't connected specifically to pylons, but I've been working on > > a module named "fixture" to test in ways like how you're talking > > about: to assert that a program interacts appropriately with its data > > model. > > > > http://code.google.com/p/fixture/ > > > > unfortunately there aren't any docs online yet and the docstrings in > > the code are still a little sparse. > > > > However, it is a fairly simple idea: you define classes descending > > from fixture.DataSet to declare data ... then you use a Fixture > > instance that knows how to load that data. For example: > > > > from fixture import DataSet, Fixture > > class EmployeesData(DataSet): > > def data(self): > > return [('bob', dict(username='bob', password='bobs_pzwrd'))] > > > > from fixture.loader import SqlAlchemyLoader > > from yourmappers import Employees # just one way, putting in global scope > > > > db = Fixture(loader=SqlAlchemyLoader(env=globals())) > > > > @db.with_data(EmployeesData) > > def test_login(data): > > assert login(data.bob.username, "secret-password") > > > > ... that sort of glosses over how sqlalchemy mappers are discovered, > > how Fixture.Data instances are delivered to tests, and what-not. And > > this code may change because I think I will merge Fixture and Loader > > definitions into one. In other words, this is still highly > > experimental! > > > > FYI: I will be presenting on this module at pycon: > > http://farmdev.com/thoughts/3/you-vs-the-real-world-testing-with-fixtures-coming-soon-/ > > > > -Kumar > > > > On 1/29/07, Carlo Sogono <[EMAIL PROTECTED]> wrote: > >> Stephen F. Steiner wrote: > >>> We just have the test harness only access the 'dummy' database. > >>> > >>> The test suite clears out the 'dummy' database, then fills it with known > >>> data (which we store in memory for quick compares). > >>> > >>> Then, we run the data sucking portion of the live code against the > >>> 'dummy' database. > >>> > >>> Compare to the stored data; they'd better match! > >>> > >>> None of that really has anything to do with Pylons specifically since > >>> the data sucking code only provides data for the front end. > >> Ok, so on a more specific note, how people here manage their test > >> databases? How do you create a dummy/temporary database in fixture, > >> populate data, do tests, then cleanup? How do I do this with PostgreSQL? > >> There seems to be no doco on this whatsoever online... > >> > >> If someone teaches me, I'll make the doco myself for everyone else to use. > >> > >> Carlo > >> > >>> Testing the front end is another issue altogether. > >>> > >>> If I understand your situation, it should be pretty simple to say "For > >>> this data, we expect this front end output." > >>> > >>> If you make sure your test data includes data that will provoke any > >>> fixed bugs, to make sure they're fixed (and stay fixed!), you should be > >>> all set. > >>> > >>> S > >>> > >>> Stephen F. Steiner > >>> Integrated Development Corporation > >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >>> www.integrateddevcorp.com <http://www.integrateddevcorp.com> > >>> (603)433-1232 > >>> > >>> > >>> > >>> > >>> > >>> > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
