use Perl

• Target Audience (Score:2)

  by Ovid (2709) on 2008.04.18 10:41 (#62278) Homepage Journal

  I can define multiple target audiences and potentially different needs they have:

  Installers like CPANPLUS

  Should ignore POD failures.

  Smoke Testers

  Should potentially alert authors to POD failures, but not fail the module because of this.

  Developers (module authors)

  All tests must pass.

  Power Users

  Test timings, code coverage over time, tagged tests, aggregating multiple TAP streams from multiple projects, critical failure response and so on.

  All of the above issues have cropped up multiple times. I've mentioned several times about the 2006 Google Test Automation Conference where people heavy test users were constantly talking about the need to have a robust solution of sharing and storing test information. Existing systems were often inflexible or did not provide a means to handle their particular needs. Mobile phone application developers needed ways of handling test information from hundreds of different phones running numerous operating systems. Others just needed ways of striping their test information to pull out statistics for just the sets of tests they were interested in.

  TAP can address these needs, but at its core, we need to keep the simple things as simple as we have them yet still find ways of serving the other needs. For namespaces, if you have an in-house 'Customer' module and someone else has an in-house 'Customer' module, they shouldn't share the same namespace if there's any risk of sharing the test results because this breaks the 'robustness' model.

  As for out-of-band information and having the rest saved to a file, that's why I keep thinking about App::Prove::State::SQLite, a simple way of storing and managing test information over time to allow Perl developers to explore what meaningful information they can glean from this. For example, tracking test timings over time [perl.org] could possibly allow one to flag potential performance problems with a change to the software.

  Reply to This

  • Re: (Score:1)

    by dagolden (6584)

    My point was that you said "casual users" shouldn't see a difference. None of the examples you gave are casual users.
    
    I think worrying about two different companies with internal "Customer" modules is over-engineering a solution that can be solved with culture instead of code. All you need to do is document that using a generic module name increases the odds of a namespace conflict. Companies that care can name their internal test modules Yoyodyne::Internal::Customer or whatever suits their fancy.
    
    I think
    • Re: (Score:2)

      by Ovid (2709)

      Casual users: How would you define 'casual user' then? Someone who never runs tests? Then that's someone who will never see an impact anyway. I thought that the installers should be the 'casual users' because most of use use CPAN or CPANPLUS or make to install a new module. Those are the ones who shouldn't see a difference and those are the ones I view as casual users.

      Namespaces: I'm rather unhappy with the 'lower-case reserved' suggestion as I think the embedded dot is a reasonable compromise, bu