Re^4: Installing Tests

Let's say I install modules Foo, Bar, and Baz. Later, I install Quux. It would be nice if I could easily rerun the tests for Foo, Bar and Baz to make sure Quux didn't break anything. That's why it would be nice to cleanly install the tests somewhere. That was I can find out if installing new modules breaks any modules I already have installed. That's the basic problem.

However, let's say when installing Bar that it had three test failures but when I checked, it turns out that those were simply bad tests. I would need some way of tracking those failures so that running tests against my already installed modules has some way of letting me know if I get different failures. It would be nice if no modules ever failed their tests, but this frequently is not an option (or I could simply not bother to install any tests which fail).

Cheers,
Ovid

New address of my CGI Course.

Comment on Re^4: Installing Tests

Replies are listed 'Best First'.
Re^5: Installing Tests by chromatic (Archbishop) on Sep 11, 2006 at 23:02 UTC
I'm not sure that this has anything to do with modules. To me it looks like a question about deployability and dependencies. Suppose you add a feature to your project in your own sandbox. All tests pass, so you check it in. Unfortunately, your co-worker checks out the project to his sandbox and several tests fail. On inspection, it turns out that you have a different version of a shared library installed and a certain function's behavior has changed in a way that affects your project. Is there a good, general solution to this problem? I don't think so. I think the easiest answer is still "Know what your dependencies are and test everything you care about that could possibly break."	[reply]

Replies are listed 'Best First'.

Re^5: Installing Tests
by chromatic (Archbishop) on Sep 11, 2006 at 23:02 UTC

I'm not sure that this has anything to do with modules. To me it looks like a question about deployability and dependencies.

Suppose you add a feature to your project in your own sandbox. All tests pass, so you check it in. Unfortunately, your co-worker checks out the project to his sandbox and several tests fail. On inspection, it turns out that you have a different version of a shared library installed and a certain function's behavior has changed in a way that affects your project.

Is there a good, general solution to this problem? I don't think so. I think the easiest answer is still "Know what your dependencies are and test everything you care about that could possibly break."

[reply]