Pull to refresh

Comments 36

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


Но также является и палиндромом :-)
Из wikipedia: «Палиндро́м (от греч. πάλιν — «назад, снова» и греч. δρóμος — «бег») — число (например, 404), буквосочетание, слово (например, топот, финск. saippuakauppias = продавец мыла — самое длинное употребительное слово-палиндром в мире) или текст, одинаково (или почти одинаково) читающиеся в обоих направлениях.»

Так что TDD палиндромом не является.
Ну вы даёте, шутку юмора не понимаете.

Прочитайте TDD «задом-наперёд», получится DDT ;-)
опять мимо, читаются по-разному
Всё с вами ясно, видимо не любители классики рока :-)
Да ты ресурсом ошибся…
да ладно вам кипятиться…
ведь правда похожи? ;)
Level100, но хороший обзор. Ждем продолжения :)
Впервые попробовал Unit тесты в последнем, уже практически готовом проекте, для тестирования запросов с клиента к серверу и проверку результата. Чтобы сразу знать, что у них там отвалилось и не работает, а не в ручную через эмулятор все проверять. Запускал их в начальный момент работы программы. Для других частей смысла тесты делать не нашел.
Хотя вот тест на проверку существования файла, это надо запомнить.
кстати, во всех жюнитовых ассерт-методах есть возможность задания первой переменной комментария к тому, что проверяет данный ассерт. вы это нигде не используете, а зря.
Зависит от того как написаны тесты — порой, для того, чтобы понять назначение теста, достаточно просто взглянуть на него — это называется самодокументированным кодом и комментарии бывают лишними.
Хотя не скрою, есть ситуации когда подобные комментарии могут быть полезны.
> Лучшее определение, которое я нашел — это тесты, которые выполняются очень быстро (менее 1 миллисекунды)
очень фиговое определение, надо сказать, ни о чем.
Согласен, что определение дано не совсем обычно, но время выполнения это основной признак модульных тестов — большинство тестов более высокого уровня выполняются дольше. Наложив ограничение на время выполнения, вы придете к пониманию того, какие вещи можно протестировать за это время и придете к выводу, что это модульные тесты в классическом их понимании (они и описаны в статье).
All Code IS Guilty Until Proven Innocent.

Одно из лучших определений концепции TDD в двух словах.
Отдельно хотелось бы акцентировать вот это:

«Почувствуйте, как каждый тест рассказывает нам историю. Это не testMethodA, testMethodB,… — это скорее похоже на сценарий.»

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

И это действительно очень удобный подход. Ведь, действительно, что нам нужно от системы? Правильно, чтобы она работала так, как нам необходимо! Соответственно, если выполняются наши правила — считаем, что система работает как надо, ни больше, ни меньше. Неспроста все большую популярность набирает логическое продолжение TDD — BDD (Behaviour-Driven Development), ставя во главу угла не объект, используемый в тесте, а часть логики, которую он реализует.
и к чему этот обзор? примеров сильно не хватает
если писать сначала тесты, а потом код, то многих проблем можно избежать с самого начала. В том числе правилного разделения кода, который тестируется разными видами тестов (unit/integration/system)
Я тут только начал осваивать тестирование, у меня вопрос:
вот если использовать SimpleTest в PHP, то как тестировать protected-методы, или это не нужно?
Обычно тестируют основные интерфейсы классов, а не реализацию, сокрытую в приватных или защищенных методах.
Ну я догадывался. А отсутствие friend-классов как в C++ меня полностью в этом убедило.
Но есть одно но — порой тесту для сравнения нужно знать делали внутренней реализации тестируемого класса, той реализации, что сокрыта в protected & private методах. И это не есть хорошо. Это можно обойти как-нибудь?
это не можно, а нужно обойти, нормально продумав архитектуру класса.
Ну, вот, скажем, есть у нас набор строк, они склеиваются protected-методом. Как вы сможете в тесте сравнить выход для заданного набора строк, не зная, как конкретно они склеиваются?
Пример:
есть массив строк array( 'str1', 'str2', 'str4' );
метод glue() возвращает одну строку, склеенную через _:
'str1_str2_str4';

Вам надо для заданного набора строк проверить работоспособность метода:
т.е. для array('Вася', 'Петя', 'Онотоле') получить 'Вася_Петя_Онотоле'
т.е. в тесте можно написать assertEquals($Class->glue(array('Вася', 'Петя', 'Онотоле')), 'Вася_Петя_Онотоле')

Так вот я описал простой метод склейки, но ведь он может быть куда более сложным.

1. Если изменится метод склейки, нужно будет менять тестовые данные
2. Нужно знать, как именно склеиваются строки, в данном случае, через '_', что тоже не очень хорошо

Вот как в этом случае продумать архитектуру класса.
Что-то неправильно я пример написал…
Ну да ладно. Сам понял, что тестовые данные для сравнения всегда будут зависеть от внутренней реализации, и никуда от этого не деться.
Это одномерный способ классификации, (по «уровню крупности»), который включает только «программные тесты», как явствует из заголовка.

Мне больше нравится классификация в форме «магического квадрата», которая была сначала предложена Брайаном Мариком, а потом идею доработал Ари Таннинен: stopandfix.blogspot.com/2009/04/all-about-testing.html

Модульные тесты — в левом нижнем углу.
Господа, а поделитесь опытом, кто какой тул использует для continuous integration? желательно с доводами почему -)
господа, разработчики! я работаю в QA уже более 5 лет со многими крупными компаниями мирового уровня. я не видел ни одного проекта, в котором бы разработчики делали не то что functional testing, они даже о unit testing не задумывались в 85% случаев. первоначально приложения ваще было невозможно запустить.
так что вы, рассказывая о unit/functional/integration фазах тестирования, немного лукавите. большинство из вас этого не делает (глобально говорю).
при этом я понимаю, что это просто перевод статьи… peace люди…
а ваще QA должны заниматься специализированные люди, а не разработчики. ведь асфальтоукладчики не бегают перед катком и не разбрасывают асфальт. их дело — ехать ровно на катке. все по специальностям. кто во чем хорош. пусть все делают профессионалы: одни кодят, другие доказывают что первые сделали свою работу не до конца хорошо )))
Разве автор статьи где-то хоть раз обмолвился о разделении труда? Нет, автор даже не пытался давать указания на то, кто какие тесты должен делать.
Разве автор заявил, что он пишет про «фазы тестирования»? Нет, он это назвал «категориями тестов».
Может быть, конечно, у Вас просто наболело за 5 лет работы в проектах, где переданное на тестирование приложение с первой попытки даже не запускается, но причём тут данная статья?
Sign up to leave a comment.

Articles