Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We are doing continuous integration at our company with TeamCity and we have unit tests running at every commit (1 min window).
Lately, we are debating on how long a batch of unit tests should last but the shortest the better.
However, I would like to know what is the best practice for the length of a batch of unit tests?
You could build priorities into your unit tests, and only use a subset as a check-in gate (Build Verification Test, or BVT). Run lower priority tests less often (e.g. per daily build, per test pass, or per product release). Then place separate execution time limits on each (or each suite) that satisfies your dev team.
I base priorities on how fast we’d jump on fixing the bug signaled by a test failure. P0 means “must-fix, even if we have to slip the schedule”, P3 means “may never fix”.
One of the teams I worked on said no more than 2 minutes per feature for BVTs, and placed no time restriction on lower priority tests. The devs had to run about 5 test suites, and it was reasonable with our volume of check-ins to queue up 10 minute buddy builds. But our “unit tests” were big-huge, special-environment-required integration tests, so YMMV.