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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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