Как поблочное тестирование улучшает производительность?

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

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

И чем раньше ошибка будет обнаружена, тем проще и дешевле ее исправить : если ошибка не успевает повлиять на других разработчиков , это тоже лучше.
Что, если разработчик считает некоторую «ошибку» (которую он не знает, является ошибкой) как особенность и начинает полагаться на нее? Что произойдет, если это будет считаться ошибкой и будет исправлено? Другой код ломается, я полагаю: - (

Приятно также то, что разработка автоматических тестов может означать, что больше разработчиков знают больше о коде приложения: особенно если некоторые тесты разрабатываются / проверяются другими разработчиками, чем те, кто написал код в первую очередь.
Не уверен, что это «хорошая практика», но если все будет сделано таким образом, это означает, что будет проводиться своего рода проверка кода - и это определенно полезно.

И поскольку все больше разработчиков знают код, другие разработчики смогут исправлять ошибки в частях, которые они изначально не разрабатывали.

«Тест» - неправильное слово для модульных тестов. «Определение поведения» - это, пожалуй, более подходящий термин.

Модульные тесты и TDD могут улучшить производительность (даже в среднесрочной перспективе) несколькими способами.

• Код с четко определенным поведением легче отлаживать, как и ожидалось.
• Код, написанный с использованием методологии TDD, имеет тенденцию иметь более четкие «швы», что позволяет независимо проверять части кодовой базы. Это упрощает поиск проблем, когда они возникают.
• Благодаря надежному набору тестов и четко определенному поведению рефакторинг становится намного, намного проще. Это позволяет решать проблемы проектирования с гораздо меньшим риском, даже если они влияют на ряд отдельных классов.
• Из-за вышеизложенного, как правило, легче определить, когда что-то идет не так, где на самом деле правильное место для исправления.
• Поскольку код, написанный на TDD, имеет тенденцию не полагаться на одноэлементное / статическое поведение или глобальное состояние, существует менее глобальное поведение. Менее глобальное поведение дает меньше побочных эффектов.

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

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

Повышение производительности с помощью модульного тестирования

Также прочтите Разработка через тестирование

Разработка через тестирование (TDD) метод разработки программного обеспечения, который использует короткие итерации разработки на основе заранее написанных тестовых примеров, которые определить желаемые улучшения или новые функции. Каждая итерация производит код, необходимый для передачи этого итерационные тесты. Наконец, программист или команда реорганизует код чтобы учесть изменения. Ключевой TDD концепция заключается в том, что подготовка тестов перед кодирование способствует быстрой обратной связи изменения. Обратите внимание, что на основе тестов разработка - это дизайн программного обеспечения метод, а не просто метод тестирование.

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

Я подозреваю, что с точки зрения производительности вопрос заключается в том, легче ли исправить ошибку в коде, которая свежа в сознании программистов, а не ошибку в коде возрастом n месяцев и т. д. Однако несколько идеалистично предполагать, что модульное тестирование (вне более широкого режима тестирования) представляет собой некую форму серебряной пули.

Как вы собирались тестировать без модульных тестов? Щелкая вокруг, визуально проверяя ответы? Стоит ли писать один раз код и многократно его запускать - это стоит или сэкономить?

Собирались ли вы проверить различные ошибки? Можете ли вы найти ошибки позже, если вы этого не сделаете, каковы относительные затраты на исправление ошибок раньше, чем позже?

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

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

Теперь я могу представить, как писать модульные тесты может быть полезным в будущем, но действительно это поможет и в краткосрочной перспективе?

Да, потому что вы заставляете своих разработчиков и архитекторов решать одну проблему за раз.

Потому что я не понимаю, как писать больше кода (= больше потенциальных ошибок) может помогите нам уложиться в сроки.

Количество дополнительного кода точно такое же. n строк логики = n строк тестов. Но, как вы знаете, необработанное кодирование - это не та часть, которая требует больше времени, в частности потому, что вы можете очень хорошо распараллелить ее. Так что написание большего количества кода - не настоящая проблема. Чтобы уложиться в сроки, вы должны создать код высшего качества , который будет выпущен, и без тестирования у вас

1. нет возможности узнать, высокое качество или нет.
2. нет способа измерить когда можно сделать релиз. (когда все тесты проходят успешно)

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

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

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

Конечно, разработчику нужно попрактиковаться в написании тестов, но вы скоро станете быстрее. Особенно, если вы привыкли к библиотекам, которые помогают писать тесты, например easymock или что-то в этом роде.

Конечно, разработчику нужно попрактиковаться в написании тестов, но вы скоро станете быстрее. Особенно, если вы привыкли к библиотекам, которые помогают писать тесты, такие как easymock или что-то в этом роде.

Конечно, разработчику нужно попрактиковаться в написании тестов, но вы скоро станете быстрее. Особенно, если вы привыкли к библиотекам, которые помогают писать тесты, такие как easymock или что-то в этом роде.

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

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

2. В модульных тестах разработчик (или пара-программист) является первым клиентом программного обеспечения. Вот почему ошибки обнаруживаются быстрее, как отмечали другие. Однако этот человек также является первым клиентом объектно-ориентированной модели, API и т. Д. Если будет задействован старший разработчик (выполняющий работу или в паре), качество улучшится с точки зрения дизайна. Это имеет среднесрочные и долгосрочные преимущества. (Это часто упускается из виду.)

3. Хорошие модульные тесты выявляют и проверяют, угловые шкафы. Эти случаи могут быть недоступны через стандартные тесты, которые разработчики запускают вручную. Если вы думаете об ошибках, обнаруженных в полевых условиях: сколько из них связано с каким-то странным состоянием? По моему опыту, лот .

Это правда, что в чужих руках модульные тесты могут ощущаться как колеса, крутящиеся в песке. Но при наличии некоторого опыта отдача того стоит, даже в краткосрочной перспективе. Да, строк рабочего кода может быть меньше, но количество ошибок будет намного выше.

Кратковременно Я думаю, что модульные тесты не очень помогают, поскольку они только сокращают время тестирования. Чем меньше проект, тем меньше от этого воздействия.

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

Как модульное тестирование повышает производительность?

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

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

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

Сценарий: Встреча проекта

Владелец продукта: «Нам нужно сделать измените на X и добавьте функцию Y. Является это выполнимо? ».

Команда:« Лучше подождать Джо, чтобы вернуться. Он написал этот код ».

Несколько недель спустя ...

Джо:« Конечно, это можно сделать, но учитывая все испытания, которые прошли в этот модуль это не быстро исправить ».

Владелец продукта:« Ой. Так что ... давайте отложим это изменение на время ... "

Я не уверен, отвечу ли я на ваш вопрос. Это действительно зависит от того, насколько краткосрочны краткосрочные.; -)

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

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