Unit тесты

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

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


Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым


Комментарии

sergey

11 Мая 2012

Интересно. Но хотелось бы чуть подробнее, для начинающих. Что такое юнит-тест на примере delphi? Как он выглядить при реализации? Как конкретно тестирует?  Как и из чего вызывается код теста?
Если я правильно понял тест это код, который обращается к классу, с целью заставить класс выдать ошибочные данные? Если ему это удается, то тест НЕ пройден?
В delphi есть полезная для отладки штука (не помню точно как она называется). Смысл в том, что она может принимать переменные любого типа. Используя это можно вызывать(заключив этот вызов в условную компиляцию) эту процедуру, скармливая ей любые типы. А затем уже смотреть в теле этой процедуры какие реальные значения имеют переменные и допустимы ли они. Но такого рода проверки это кажется называется "экстремальное программирование". Поэтому немного не по теме.


Verus

11 Мая 2012

Михаил у Вас первый абзац повторяется


alex.mrnv

11 Мая 2012

Да, Михаил, интересно. Я вот на ту же тему у Макконелла мысль вычитал, там даже пример приведён на счёт строительства моста, и даже фото разрушенного, это глава 5. Проектирование при конструировании. Это хорошая метафора, и вот что сам Макконнелл пишет о метафорах:"Метафоры имеют эвристическую, а не алгоритмическую природу, поэтому они не исключают друг друга. Если хотите, можете представлять разработку ПО как написание письма, комбинируя эту метафору с вождением автомобиля, охотой на оборотней или оразом динозавра увязшего в смоляной луже. Используйте любые метафоры или их комбинации, которые стимулируют ваше мышление или помогают общаться с другими членами группы." Далее приводит Дейскстру:"Ни один человек не обладает интеллктом, способным вместить все детали современной программы, поэтому не следует пытаться охватить всю программу сразу. Вместо этого мы дожны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени." Но мне нравится глава 8. Зашита от защитного программирования, которая начинается цитатой из Марка Твена "Слишком много чего-либо - это плохо, но слишком много виски - это просто достаточно." Избыток защитного программирования сам по себе создает проблемы. Если вы проверяете данные, передаваемые через параметры, во всех возможных местах, всеми возможными способами, ваша программа будет слишком большой и медленной.  


google

11 Мая 2012

sergey http://www.youtube.com/watch?v=nm_yq9jYckc после этого вопросы должны отпасть сами собой, unit тесты это не роскошь в современном мире это необходимость, которой пользуюсь уже больше 3 лет!!!


Добавить Комментарий

Еще что-нибудь

Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.

О блоге

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

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповедания, на русском или английском языке.

Пишите мне