Як покращити тестування власного коду [закрито]

Сьогодні я перевірив зміну якогось коду, який виявився, що він взагалі не працює через щось досить дурне, але дуже важливе. Мені це дуже погано, і я сподіваюся, що нарешті щось з цього навчусь. Дурне в тому, що я робив це раніше і завжди кажу собі, наступного разу я не буду таким дурним ... Потім це станеться знову, і я відчуваю себе ще гірше.

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

Отже, зараз я запитую вас, хлопці: чи маєте ви певні основні моменти під час тестування свого коду?

Пишіть тести, перш ніж вносити зміни до коду.

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

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

Не забудьте перевірити кейси! Багато помилок тому, що було протестовано найпоширеніші дії, але не менш поширені.

Дотримуйтесь технічних порад у технічно орієнтованих відповідях; це хороші речі. Моя відповідь більше стосується ставлення.

Відчуття помилок щодо того, що роблять помилку, який час від часу робить кожен розробник, просто абсурдно, і не допомагає вам не допустити такої помилки в майбутньому. Поки ти сидиш там, відчуваючи себе погано, збірка все одно порушена, ти знаєш? І тоді ваша робота - це уникнення помилок, які, як я знаю, щодня встають з ліжка - захоплююча пригода, правда?

Я чув про компанії, де перевірка зламаного коду є приводом для громадського ганьби. Я навіть не можу опустити голову навколо викривленого, братаного хлопця, мислення молодшого вищого рівня, яке призвело б до такої поведінки. Навряд чи може бути що-небудь контрпродуктивніше для керівника команди чи менеджера.

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

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

Іншою важливою практикою тестування є написання тесту та переконайтеся, що він не вдається принаймні один раз ДО ПІД написання коду. Все легко зіпсувати і написати тест на тавтологію, який випадково не перевіряє стан, який ви перевіряєте. Помилкові запевнення майже (а іноді й гірші), ніж відсутність запевнень.

Одна ідея, яку я час від часу використовував, це така,

створіть гілку та зламайте ваш код, запустіть тест і переконайтесь, що тест виявляє помилку.

Чи є у вас певні основні моменти під час тестування вашого коду?

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

Деякі додаткові загальні моменти:

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