Лучшие практики тестирования производительности при выполнении TDD?

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

Я подозреваю, что применение TDD для повышения производительности привода является ошибкой. Во что бы то ни стало, используйте его, чтобы получить хороший дизайн и рабочий код, и используйте тесты, написанные в ходе TDD, чтобы обеспечить постоянную корректность - но как только у вас есть хорошо продуманный код и солидный набор тестов, вы в хорошей форме для настройки и применяются различные (от TDD) методы и инструменты.

TDD дает вам хороший дизайн, надежный код и тестовую сеть безопасности. Это делает вас хорошим местом для тюнинга, но я думаю, что из-за проблем, которые вы и другие упоминали, это просто не приведет вас намного дальше по дороге тюнинга. Я говорю это как большой поклонник и сторонник TDD и практик.

Запишите время выполнения текущего кода.

if (newCode.RunningTime >= oldCode.RunningTime) Fail

In many server applications (might not be your case) performance problem manifest only under concurrent access and under load. Measuring absolute time a routine executes and trying to improve it is therefore not very helpful. There are problems with this method even in single-threaded applications. Measuring absolute routine time relies on the clock the platform is providing, and these are not always very precise; you better rely on average time a routine takes.

My advice is:

• Use profiling to identify routines that execute the most times and take most time.
• Use tool like JMeter or Grinder to elaborate representative test cases, simulate concurrent access, put your application under stress and measure (more importantly) throughput and average response time. This will give you a better idea of how your application is behaving as seen from the outside perspective.

While you could use unit tests to establish some non functional aspects of your application, I think that the approach given above will give better results during optimization process. When placing time-related assertions in your unit tests you will have to choose some very approximative values: time can vary depending on the environment you are using to run your unit tests. You don't want tests to fail only because some of your colleagues are using inferior hardware.

Tuning is all about finding right things to tune. You already have a functioning code, so placing performance related assertions a posteriori and without establishing critical sections of code might lead you to waste a lot of time on optimizing non-essential pieces of your application.

Еще не сталкивался с такой ситуацией;) однако, если бы я это сделал, вот как бы я поступил. (Я думаю, что я взял это из книги Дэйва Астела)

Шаг # 1: Придумайте спецификацию для «приемлемой производительности», поэтому, например, это может означать: «Пользователь должен уметь делать Y за N секунд ( или миллисекунды) '
Шаг № 2: Теперь напишите неудачный тест. Используйте свой удобный класс таймера (например, .NET имеет класс StopWatch) и Assert.Less (actualTime, MySpec)
Шаг № 3: Если тест уже пройден, все готово Если красный, вам нужно оптимизировать и сделать его зеленым. Как только тест станет зеленым, производительность станет «приемлемой».

Запустите тесты + профилирование на сервере CI. Вы также можете периодически запускать нагрузочные тесты.

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

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

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

Лично я никогда не видел критериев производительности типа «должен быть быстрее, чем в последней версии», потому что это так трудно измерить.

Вы говорите: «серьезно нуждается в настройке производительности». Куда? Какие запросы? Какие функции? Кто говорит, бизнес, пользователи? Какова приемлемая производительность? 3 секунды? 2 секунды? 50 миллисекунд?

Отправной точкой для любого анализа производительности является определение критерия прохождения / отказа. Как только у вас есть это, Вы МОЖЕТЕ автоматизировать тесты производительности.

Для надежности вы можете использовать (простой) статистический подход. Например, выполнить один и тот же запрос в тех же условиях 100 раз. Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

Для надежности вы можете использовать (простой) статистический подход. Например, выполнить один и тот же запрос в тех же условиях 100 раз. Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

Для надежности вы можете использовать (простой) статистический подход. Например, выполнить один и тот же запрос в тех же условиях 100 раз. Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

Вы можете использовать (простой) статистический подход. Например, выполнить один и тот же запрос в тех же условиях 100 раз. Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

Вы можете использовать (простой) статистический подход. Например, выполнить один и тот же запрос в тех же условиях 100 раз. Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

Если 95% из них возвращаются менее чем за n секунд, это проход.

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).

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

Наличие стабильной среды всегда сложно сделать при тестировании производительности, независимо от того, выполняете ли вы автоматические тесты или нет. Вы будете иметь эту конкретную проблему независимо от того, как вы развиваетесь (TDD, Waterfall и т. Д.).