Perhaps you think this is a "legacy" issue, but it's not. Write some more systems-oriented code (not neccessarily simple Perl scripts or even Perl applications) and you will see what I mean. Anyhow, if you don't understand my caution, it doesn't apply to you (yet)... which is ok.

As for running builds as part of the test suite, umh, the developers had better run the builds themselves, else you have a serious issue of incompetance to deal with if they think they can check in uncompiled code! At least nightly builds are a very good thing, of course.

that a thing builds on your system doesn't mean it builds freshly checked out. And testing without a fresh build from a freshly updated <SourceControlSystemOfYourChoice>-snapshot wouldn't be proper testing IMO. If such a thing happens here, the developers in question get mails, including all error-messages and all changes with commit-comments done since the last build at most 15minutes after the checkin, very sensible and cool thing to do, really! (we're using CruiseControl, maybe there's a perl-solution out there I don't know of...)

So congrats for never forgetting to check in everything, and for never producing incompatibilities against code-changes a co-worker did make simultanious to yours, on different files... :-P

Our builds do notify users of breakages, however running builds is not the same as testing, I don't know how this got mixed in here...it's not related.

And again, extra testing by way of machine is nice, but it's just that -- extra testing. It's nice if you can ad it, but sometimes all you can get is 20% (or less) coverage. Here, we have a lot of hardware specific stuff (RAID cards and what have you) and we'd be lucky to get 1% coverage on the 'software' components.

Anyhow, no harm done, no offense taken, etc, etc :)