Скорость выполнения модульных тестов (сколько тестов в секунду?)

К какой скорости выполнения вы стремитесь с помощью модульных тестов (# test per second)? Как долго слишком долго для индивидуального модульного теста?

Мне было бы интересно узнать, есть ли у людей какие-то конкретные пороги для определения, являются ли их тесты слишком медленными, или это просто когда трение длинного набора тестов берет верх над вами?

Наконец, когда вы решаете, что тесты должны выполняться быстрее, какие методы вы используете для ускорения тестов?

Примечание: интеграционные тесты, очевидно, снова другой вопрос. Речь идет о модульных тестах, которые необходимо запускать как можно чаще.


Ответ roundup: Спасибо за отличные ответы до сих пор. Большинство советов, кажется, не беспокоиться о скорости-сосредоточиться на качестве и просто выборочно запустить их, если они слишком медленные. Ответы с конкретными номерами включили

Не уверен, правильно ли отмечать один как «принятый ответ», когда они все полезны 🙂

11 ответов

  1. Я склонен больше фокусироваться на читаемости своих тестов, чем на скорости. Тем не менее, я все еще пытаюсь сделать их достаточно быстрыми. Я думаю, если они работают на порядок миллисекунд, вы в порядке. Если они выполняют второй или более за тест… тогда вы, возможно, делаете что-то, что должно быть оптимизировано.

    Медленные тесты только становятся проблемой, поскольку система созревает и заставляет сборку занимать часы, в этот момент Вы, скорее всего, столкнетесь с проблемой многих видов медленных тестов, а не с одним или двумя тестами, которые можно легко оптимизировать… таким образом, вы должны, вероятно, обратить внимание сразу, если вы видите много тестов, выполняющихся сотни миллисекунд каждый (или хуже, секунд каждый), а не ждать, пока он доберется до сотен тестов, занимающих эту длинную точку (в этот момент это будет действительно трудно решить проблему).

    Даже если это так, это только сократит время между тем, когда ваша автоматическая сборка выдает ошибки… что нормально, если это час спустя (или даже несколько часов спустя), я думаю. Проблема заключается в их выполнении перед регистрацией, но этого можно избежать, выбрав небольшое подмножество тестов для запуска, которые связаны с тем, над чем вы работаете. Просто исправьте сборку, если вы возвращаете код, который нарушает тесты, которые вы не запускали!

  2. Если мы говорим о строго модульных тестах, я бы стремился больше к полноте, чем к скорости. Если время выполнения начинает вызывать трение, разделите тест на различные проекты / классы и т.д., и выполнять только тесты, связанные с тем, над чем вы работаете. Позвольте серверу интеграции выполнить все тесты при проверке.

  3. В настоящее время мы находимся на 270 тестах примерно в 3.что-то секунды. Существует, вероятно, около 8 тестов, которые выполняют файл ввода-вывода.

    Они запускаются автоматически при успешном построении наших библиотек на каждой машине инженеров. Мы имеем более обширное (и требующее много времени) дым-испытание которое сделано машиной строения каждую ночь, или может быть начато вручную на машине инженеров.

    Как вы можете видеть, мы еще не достигли проблемы тестов, требующих слишком много времени. 10 секунд для меня-это момент, когда он начинает становиться навязчивым, когда мы начинаем подходить, что это будет что-то, на что мы посмотрим. Скорее всего, мы переместим библиотеки нижнего уровня, которые являются более надежными, поскольку они редко меняются и имеют мало зависимостей, в ночные сборки или конфигурацию, где они выполняются только машиной сборки.

    Если вы обнаружите, что требуется больше, чем несколько секунд, чтобы выполнить около сотни тестов, вам, возможно, потребуется изучить, что вы классифицируете как модульный тест и будет ли лучше относиться к тесту дыма.

    ваш пробег, очевидно, будет сильно варьироваться в зависимости от вашей области развития.

  4. I judge my unit tests on a per test basis, not by by # of tests per second. The rate I aim for is 500ms or less. If it is above that, I will look into the test to find out why it is taking so long.

    When I think a test is to slow, it usually means that it is doing too much. Therefore, just refactoring the test by splitting it up into more tests usually does the trick. The other times that I have noticed my tests running slow is when the test shows a bottleneck in my code, then a refactoring of the code is in order.

  5. Все модульные тесты должны выполняться за секунду (то есть все модульные тесты, объединенные, должны выполняться за 1 секунду). Теперь я уверен, что это имеет практические пределы, но у меня был проект с 1000 тестов, которые работают так быстро на ноутбуке. Вы действительно хотите эту скорость, чтобы ваши разработчики не боялись рефакторинга какой-то основной части модели (например, дайте мне пойти выпить кофе, пока я запускаю эти тесты…Через 10 минут он возвращается).

    Это требование также заставляет вас правильно разработать приложение. Это означает, что ваша модель домена является чистой и содержит ноль ссылок на любой тип Persistence (файловый ввод-вывод, база данных и т.д.). Модульные тесты все о тестировании этих бизнес-отношений.

    Это не значит, что вы игнорируете тестирование базы данных или сохраняемость. Но эти проблемы теперь изолированы за репозиториями, которые могут быть отдельно протестированы с помощью интеграционных тестов, расположенных в отдельном проекте. Модульные тесты выполняются постоянно при написании кода домена, а затем интеграционные тесты выполняются один раз при регистрации.

  6. Точка Данных — Регрессионные Тесты Python

    Вот цифры на моем ноутбуке для запуска «make test» для Python 2.5.2:

    • количество тестов: 3851 (прибл)
    • время выполнения: 9 мин, 6 сек
    • скорость выполнения: 7 тестов / сек
  7. How long is too long for an individual
    unit test?

    I’d say it depends on the compile speed. One usually executes the tests at every compile. The objective of unit testing is not to slow down, but to bring a message «nothing broken, go on» (or «something broke, STOP«).

    I do not bother about test execution speed until this is something that starts to get annoying.

    The danger is to stop running the tests because they’re too slow.

    Finally, when you do decide the tests
    need to run faster, what techniques do
    you use to speed up your tests?

    First thing to do is to manage to find out why they are too slow, and wether the issue is in the unit tests or in the code under test ?

    I’d try to break the test suite into several logical parts, running only the part that is supposedly affected by the code I changed at every compile. I’d run the other suites less often, perhaps once a day, or when in doubt I could have broken something, and at least before integrating.

  8. Цель-100 тестов в секунду. Вы доберетесь туда, следуя правилам модульных тестов Майкла Фера .

    Важный момент, который возник в прошлом обсуждении CITCON, заключается в том, что если ваши тесты не так быстры, вполне вероятно, что вы не получаете преимущества проектирования модульного тестирования.

  9. Some frameworks provide automatic execution of specific unit tests based on heuristics such as last-modified time. For Ruby and Rails, AutoTest provides much faster and responsive execution of the tests — when I save a Rails model app/models/foo.rb, the corresponding unit tests in test/unit/foo_test.rb get run.

    I don’t know if anything similar exists for other platforms, but it would make sense.

  10. One of the most important rules about unit tests is they should run fast.

    How long is too long for an individual unit test?

    Developers should be able to run the whole suite of unit tests in seconds, and definitely not in minutes and minutes. Developers should be able to quickly run them after changing the code in anyway. If it takes too long, they won’t bother running them and you lose one of the main benefits of the tests.

    What kind of execution rate do you aim for with your unit tests (# test per second)?

    You should aim for each test to run in an order of milliseconds, anything over 1 second is probably testing too much.

    We currently have about 800 tests that run in under 30 seconds, about 27 tests per second. This includes the time to launch the mobile emulator needed to run them. Most of them each take 0-5ms (if I remember correctly).

    We have one or two that take about 3 seconds, which are probably candidates for checking, but the important thing is the whole test suite doesn’t take so long that it puts off developers running it, and doesn’t significantly slow down our continuous integration build.

    We also have a configurable timeout limit set to 5 seconds — anything taking longer will fail.