Как улучшить тестирование вашего собственного кода [закрыто]

12

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

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

Итак, теперь я спрашиваю вас, ребята: есть ли у вас определенные основы при тестировании кода?

Питер
источник
1
Это может помочь: programmers.stackexchange.com/questions/45479/…
Амир Резаи

Ответы:

17

Напишите тесты, прежде чем вносить изменения в код.

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

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

стихарь
источник
Это действительно хороший совет, может потребоваться немного больше времени для исправления ошибки, но, черт возьми, это не заставит меня снова делать подобные ошибки, и это позволит мне писать более стабильный код в целом.
Питер
@ Питер должен сэкономить время на обслуживание в долгосрочной перспективе. Вам нужно будет тратить меньше времени на ручное тестирование исправлений, а также тесты будут на месте при следующем редактировании кода. Иногда вы можете даже обнаружить, что быстрое написание модульного теста, который воспроизводит ошибку, может ускорить ее отладку и исправление.
Alb
@ Питер Я часто повторяю ошибку несколько раз, исправляя ее. Написание небольшого теста вместо этого обычно экономит время, не говоря уже о том, что вы можете быть абсолютно уверены, что он работает (и будет работать в будущем).
DasIch
это такой замечательный совет, приятель, большое спасибо!
Шахир
@Alb или даже в краткосрочной перспективе.
3

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

HLGEM
источник
Имхо настоящая жемчужина в нахождении этих крайних случаев. Меня часто удивляют ошибки, возникающие в системе, просто потому, что мы не думаем о конкретном сценарии.
Питер
2

Следуйте техническим советам в технически ориентированных ответах; это хорошо. Мой ответ больше об отношении.

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

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

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

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

Дэн Рэй
источник
Я понимаю, что вы говорите о публичном позоре, но в то же время неприятно быть заблокированным, потому что сборка не работает, потому что Джо Блоггс не
собрал
@tenpn - полностью. Но обратная сторона того, что я говорю, верна и для Джо Блоггса. Он также не его код. Как коллеги, мы должны сопротивляться желанию превратить Джо в идиота в наших глазах, потому что он допустил ошибку, которую мог совершить любой из нас.
Дэн Рэй
@tenpn на самом деле, вы также можете обвинить систему в том, что она не провела автоматическое тестирование сборки перед передачей изменений в trunk / master.
Дэвид
2
@tenpn - Никто не бьет ваших коллег.
Дэн Рэй
1
Что если изменение не сломает сборку? Здравый смысл строить свой код перед регистрацией. Не так очевидно тестировать ваш код всеми возможными способами. Там всегда есть какой-то сценарий, который вы не могли бы иметь хотя. Только сегодня я столкнулся с ошибкой округления с плавающей запятой, которая возникает, только если у вас правильные (неправильные) числа
Питер
2

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

Uri
источник
0

Одна идея, которую я использовал время от времени, заключается в следующем,

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

Захари К
источник
0

Есть ли у вас определенные правила при тестировании вашего кода?

  • Всегда проводите модульное тестирование своего кода и старайтесь охватить как можно больше.

Некоторые дополнительные общие моменты:

  • потратить некоторое время на разработку и планирование, прежде чем приступить к написанию кода
  • рефакторинг вашего кода!
BЈовић
источник