Как часто вы запускаете и тестируете свой код во время программирования? [закрыто]


16

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

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

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

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


3
Написание целой подпрограммы занимает несколько часов или дней?

1
@Thorbjorn Подпрограмма длиной около 999 строк, и она запутана: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)и это только одна строка.
Матин Улхак

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

Ответы:


6

Это действительно зависит от аспекта проекта, над которым вы работаете.

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

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

  • Для UX-дизайна я использую какой-то визуальный дизайнер, который всегда выглядит так, как он будет работать (или близко к нему). По сути, это всегда компиляция кода проекта.


63

Лично я должен работать небольшими порциями, потому что я недостаточно умен, чтобы хранить часы в своем биологическом кеше L1. Из-за моих ограниченных возможностей я пишу небольшие связные методы и объекты дизайна, чтобы иметь очень слабую связь. Более мощные инструменты и языки упрощают кодирование без сборки, но для меня все еще есть ограничение.

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


12
Upvote за "... не достаточно умный ..." Я чувствовал себя так в течение довольно долгого времени.
leed25d

4
А как насчет вашего кеша второго уровня?
Матин Улхак

Я собирался поднять это, но счет на 42 ...
Уэйн Вернер

Более новые модели имеют гораздо большие кэши L1. Когда ты купил свой? Вы можете пойти на обновление оборудования.
Питер Айтай

Ну, это не возраст модели, а тот факт, что это была «бюджетная» линия. :(
dss539

17

Мне нравится писать свой тест, прежде чем я напишу свой код реализации. Мне это нравится по трем причинам:

  1. Написание тестового кода заранее помогает мне продумать, как использовать мой код. Это помогает мне думать о крайних случаях, о которых я не задумывался, когда первоначально проектировал свою программу.
  2. Я знаю, что я закончил писать код реализации, когда все мои тесты пройдены.
  3. Привыкание писать тесты до написания кода также дает возможность доказать, что ваш код не добавил никаких новых ошибок (при условии, что вы написали хорошие тестовые примеры).

2
«Я знаю, что закончил писать код реализации, когда все мои тесты пройдены». - Как вы определяете, написали ли вы все необходимые тесты?
dss539

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

4
@ Дэвид - как вы формально доказываете, что ваше формальное доказательство не имеет ошибок? Как вы официально подтверждаете, что воспринимаемые вами требования соответствуют действительным требованиям? Вы можете формально доказать, что одно описание соответствует другому, но вполне возможно, что оба описания неверны одинаково, особенно если оба описания написаны одним и тем же человеком. Написание вещей в математической записи не делает людей непогрешимыми. Огромное количество математических «доказательств» оказалось (после долгих периодов очень детальной проверки) ошибочными.
Steve314

1
@ Steve314: AFAIK, формально доказывая правильность алгоритма, вы точно и кратко указываете ожидаемую корректность. Вы приносите хороший момент , хотя, что определение «правильности» не может на самом деле быть правильным.
Дэвид Вайзер

1
@ dss539, что исходит из вариантов использования, которые программа намеревается реализовать.

4

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

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

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

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

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


3

Я компилирую и проверяю, выполняется ли одно из следующих условий:

  • Последняя компиляция была 15 минут назад
  • Последняя компиляция была 25 строк назад
  • Новая функция / подпрограмма была реализована
  • Существенное изменение
  • Новая функция (или ошибка, замаскированная под функцию)
  • Исправлена ​​ошибка (удалена «фича»)
  • Мне скучно

1

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

С другой стороны, если я пишу код на Лиспе, я попробую каждую функцию после ввода.

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


1

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


1

Трижды в час, нужно это или нет.

Мы выполняем тестирование в первую очередь и передаем только рабочий код в VCS. Smolderbot выходит и проверяет репо каждые 20 минут и запускает набор тестов. Любые ошибки немедленно отправляются всей команде разработчиков для немедленного исправления.


1

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

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


0

Для меня; -
Короткие сроки (не так много времени, чтобы думать) - написать код, компилировать, тестировать. Отладка
Достаточное время - пока (сделано) {написать небольшой код, скомпилировать}, протестировать, отладить


Я считаю, что первое занимает больше времени, чем второе: вам нужно отладить больше, если у вас очень маленький цикл тестирования / записи.
Фрэнк Шиарар

Может быть. Но короткие сроки означают, что задница в огне, и менеджеру нужен отчет, в котором говорится, что какая-то задача выполнена на 100%.
Маной Р

0

Я тестирую для каждой концепции кодирования. Иногда это функция или класс, а иногда это не более чем оператор if. Как только концепция сработает, переходите к следующему.


0

Я пытаюсь написать тесты перед кодом. Я запускаю свои тесты по крайней мере дважды перед фиксацией. Затем он снова запускается с сервером непрерывной интеграции.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.