Looking for feedback on whether the following idea has unforeseen consequences.
Currently we have over 16,000 tests scattered over 347 directories, 314 .t files (more directories than .t files?), 419 xml documents, 256 yaml documents and 48 supporting .pm files. So if you want to write more tests for Pips3::Domain::Broadcast, you naturally 'ack' for it: t/unit/persister/dbic/persist.t t/unit/persister/mapper/dbic/broadcast.t t/unit/persister/mapper/dbic/schedule.t t/unit/persister/mapper/dbic.t t/unit/importer/data_collection/update_failed_schedule_status.t t/unit/importer/data_collection/find_by_pid.t t/unit/importer/validator/format_on_top_level_object.t t/unit/importer/validator/no_overlapping_broadcasts.t t/unit/importer/validator/schedules_have_broadcasts.t t/unit/importer/validator/genre_on_top_level_object.t t/unit/importer/validator/broadcasts_inside_schedule.t t/unit/importer/validator/masterbrand_on_top_level_object.t t/unit/importer/validator/incorrect_revision.t t/unit/importer/data_collection.t t/unit/domain/add_blank_change_event.t t/unit/domain/exists_in_pips.t t/unit/extractor/xml/tva/broadcast.t t/unit/extractor/xml/tva/schedule.t That's completely unworkable. Our test directories are based around functionality, but that makes it very difficult to find the code you're trying to test. These are developer tests, not customer tests! After a lot of research into our test suite, I've recommend something similar to the following: Mirror the test directories after the code in lib/. So we might have this for *all* tests for Pips3::Domain::Broadcast: t/pips3/domain/broadcast-unit.t t/pips3/domain/broadcast-roundtrip.t t/pips3/domain/broadcast-from_tva.t t/pips3/domain/broadcast-collections.t And so on. The -$name.t at the end designates the responsibility you're testing. Now finding tests is deterministic. Everyone has agreed that this is much better. The objection raised was that some functionality could cover many modules, but as jplindstrom pointed out, that functionality is ultimately driven through one bit of code in one module, so that's where it would go above. For our api, we're thinking of something like this: t/uri/api/v1/changes-no_changes.t t/uri/api/v1/changes-broadcast.t And so on. The directory structure would look roughly like the URI it would be accessed via. Not only are tests easier to find, a simple 'ls' in one directory shows what we're testing. Does anyone do anything like this and do you see any drawbacks? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
