On Saturday 14 November 2015 22:35:26 Chris Cannam wrote: > > On Sat, Nov 14, 2015, at 01:55 PM, David Faure wrote: > > > > Right now they are fast, but over time they will grow, and you guys will > > get really annoyed at being slowed down in the edit-compile-run cycle by > > 1 minute of unit tests running. > > If it takes more than a tenth as long to run as it does to build, then > it isn't a unit test.
Yes. I'm interested in autotests in general, not just unit tests. The existing 3 tests in test/ are unit tests, they run in 0.3s. The "loading data/examples/*.rg and exporting to .ly" test I'm writing is a higher-level autotest, and it needs 23s (although I'm hoping to shorten that a little bit by avoiding the audio initialization, as per my other mail). Still I expect it will take 20s, which is not something we want in every build. We can of course separate unit tests from integration tests, and only run fast unit tests at make time. If everyone is OK with that I can look into it. > And if you're annoyed by a minute of tests > running, you're going to be far more annoyed by ten minutes of tests > building (which is there is also that question about whether to build > them or not). They build fast, that's not the issue. > As long as everything is happening in-process it should be > quite reasonable to run the tests every time they're built, and when > there's no CI, it seems to me like a good idea from a practical point of > view as well. No strong objection from me, but as soon as someone mentions turning off autotests to speed up development, I would encourage to reconsider (it's worse to not even build them than to build and only run occasionally). -- David Faure, [email protected], http://www.davidfaure.fr Working on KDE Frameworks 5 ------------------------------------------------------------------------------ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
