in reply to Re^2: Installing Tests
in thread Installing Tests

Install them where?

Install what where? Modules? That part really ought to work. If it doesn't, run the tests against the installed modules and see if they fail. Note that this part of the building and installation process requires extra work to set @INC appropriately. If you're building and installing a module, you can run the tests again, avoid doing that extra work, and let them test the just-installed modules.

If you mean something different by them, you've really confused me and I really don't understand what you're saying. I may not anyway.

What problem are you trying to solve by installing tests? When will you run the installed tests? What information will running installed tests give you? Why is that information valuable?

Replies are listed 'Best First'.
Re^4: Installing Tests
by Ovid (Cardinal) on Sep 11, 2006 at 21:57 UTC

    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.

[reply]

      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]

In Section Meditations