Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am working on adding test coverage for an application that previously didn't have any. One additional requirement that emerged is that one of the background processes should be able to process 100,000 rows at a time.

I've written a unit test that ensures that the background process is able to work with the 100,000 entities without crashing the interpretter (PHP) on a 4.0MB memory limit. But each test run takes close to 4 minutes to finish. All other tests take just 10 seconds to run.

Can this be approached differently than a unit test?

share|improve this question
that kind of test is not for unit test but integration test –  ratchet freak May 8 '13 at 13:08
Performance is not a functional requirement. A functional requirement is a definition of correct behavior; that the program comes up with the right answer or performs the correct action in a specific use case. Unit tests can only verify functional requirements; nonfunctional requirements that are still directly measurable by running code (performance, fault tolerance, interop) can be verified with tests of a larger scope, such as automated acceptance tests. –  KeithS May 8 '13 at 16:08
A minor point (but one I've seen cause confusion before); just because some of your automated tests are too time consuming or have too many external dependencies to fit within the traditional unit test definition doesn't mean you can't use the same test framework as your unit tests. You should however keep time consuming tests segregated from the rest so that you can run the fast tests without having to wait on the slow ones to get results displayed. –  Dan Neely May 8 '13 at 18:21

3 Answers 3

up vote 13 down vote accepted

I'm not sure how you have your test cases structured, but that sounds more like a system test or acceptance test than a unit test to me.

In my opinion, unit tests should be concerned with testing that functionality works and exercising various code branches. An example of a unit test would be processing a single record, and you might have a few variations of this record to force your testing to go down certain paths and confirm your results are what is expected. Your unit tests can be used for regression and smoke testing as well - things that you run on a regular basis (nightly, after a build, locally in a development environment before a code review, and so on).

Your system level and acceptance tests aren't run as frequently - running automated system tests nightly would be as frequent as I'd expect. These would be more intensive tests that would focus on system performance, memory consumption, timing, and behavior with other systems. Having it automated, much like your unit tests, are a good thing, but I wouldn't want to bog down your unit test suite or regression test suite with such long-running activities.

share|improve this answer

This is more along the lines of a load test. Unit tests should be about whether the code produces correct results. Load tests are geared toward testing whether the system meets certain volume and timing requirements, and are typically run at a higher level of evaluation than unit tests.

If the system could only handle 99,000 records, what level of failure is that and what does it mean. What if it was desired to process 100,000 records in three minutes but your test indicates it took 4 minutes. Load tests are not so much about absolute failure or success. They are more aligned to testing minimum levels of performance and provide guidance toward needed scalability enhancements.

Edit: Sorry, I guess I didn't really answer your title question. I would say that this is a valuable test, but I think you are doing it wrong to consider this as part of your unit tests.

share|improve this answer

What you tried to do it for the functional testing.

Unit tests have to be FIRST (Fast Isolated Repeatable Self-verifying

The faster your tests run, the more often you’ll run them. Tests take half a minute to run? You’ll maybe run them every 5 minutes instead of every few seconds. Tests take over two minutes to run? You might run those tests once every half hour, and you can write a lot of questionable code in that time! Tests take ten, fifteen, or more minutes to run? Forget it. You’ll run those a few times per day at best.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.