Author Topic: Testing blockers (Read 2602 times)

Eileen · March 23, 2011, 05:09:29 pm

I find the test suite harder to get going on than it should be & am reluctant to help people set it up because mostly I feel like mine will break if I look at it the wrong way

Apart from the obvious speed issue & the fixed Microsoft issues I also struggle with generating the DAO. I wind up having more than one branch of SVN on my computer running tests. They both use the same db so they run off one settings file for the tests to run but I need another to generate the DAO & that requires a path to the civicrm root in the civicrm.settings.php file. I don't necessarily have configured websites to run the tests & have to butcher up some semblance of a path to the settings file because I'm not running a website - just a test suite and my folders are organised around other needs.

I feel like I should be able to generate the DAO more easily. I know that generating the tables requires info about the DB but surely the DAO could be generated using best-guess as to constants if there is no settings files available?

xavier · April 03, 2011, 01:22:10 am

Hi,

First, I'm obviously sharing the pain about speed and setup (probably counting in days the amount of time spent to get the beast working).

My config now is to have the test running on the same svn check out than I use for my trunk site. They have different DBs, but same DAO and all, so can re-generate them (and use civicrrm/ajax/rest to quick test too).

As for the speed, if you are sure that either you are not modifying the DB or that your setup teardown puts the test in a proper shape, you can add an attribute to your class:

/* This test case doesn't require DB reset */
public $DBResetRequired = false;

X+

Eileen · April 03, 2011, 01:32:25 am

Yes, obviously there are various ways around things but ... surely it should be possible to generate the DAO based on an educated guess without it even needing to access civicrm.settings.php

Code: [Select]

As for the speed, if you are sure that either you are not modifying the DB or that your setup teardown puts the test in a  proper shape, you can add an attribute to your class:

The second item here is intriguing - but of course it's a test-by-test sanity check to introduce it.

xavier · April 03, 2011, 01:54:24 am

Quote from: Eileen on April 03, 2011, 01:32:25 am

surely it should be possible to generate the DAO based on an educated guess without it even needing to access civicrm.settings.php

Err, good point. No idea why it's needed indeed.

Quote from: Eileen on April 03, 2011, 01:32:25 am

it's a test-by-test sanity check to introduce it

Now that the API is in good shape, should be easy(ier) to add the needed creation in the setup and deletions in the teardown. This obviously injects a dependency where the api needs to work to get the test work and it's not very good, but IMO better than spending half an eternity when you run the tests.

IMO, the behaviour should be:
- if running an individual test suite, don't reset the db, and do the needed to fix the setup/teardown. Add an option --force-reset for the odd case where you are screwing up the db badly
- if running several test suites, reset the db if there is an error in one of the tests

And the db reset should be moved at the end of the tests, not at the start (not sure if Michau did it already or not). Each test assumes a clean state before, and decides if it needs to be cleaned after.

CiviCRM Community Forums (archive)

News:

Author Topic: Testing blockers (Read 2602 times)

Eileen

Testing blockers

xavier

Re: Testing blockers

Eileen

Re: Testing blockers

xavier

Re: Testing blockers