Comments 12
Почему в блоге .NET? Помоему описанные принципы справделивы для любого языка. Я бы запостил в Тестирование
По поводу движка для интеграционного тестирования – идея не новая, мы давно и успешно используем Fitnesse.
Для описания Fit-теста используется HTML документ, который вполне может создать тестировщик и передать программисту для использования. В документе описываются входящие данные, операции над ними и ожидаемые результаты.
Для описания Fit-теста используется HTML документ, который вполне может создать тестировщик и передать программисту для использования. В документе описываются входящие данные, операции над ними и ожидаемые результаты.
Я не претендую на новизну идеи. С Fitnesse не знаком и его возможностей не знаю. Но поглядев на их Wiki могу сказать, что движок Fitnesse очень отличен от моего:
1) Отношение к тестовым данным.
Насколько я понял, тестовые данные всегда задаются в табличном виде. Несколько аргументов и несколько проверяемых критериев. Но что делать в Fitnesse когда тестовые данные — это целый файл? Логично именно файл передавать как данные, если тестируется конвертирование документа в другой формат, к примеру.
У меня тестовые данные находятся либо в самой спецификации, либо в отдельном файле. В обоих случаях файлы хранятся в DLL тестового проекта как Embedded Resource. Это позволяет:
— Включать интеграционные тесты вместе со всеми данными в систему контроля версий.
— Всегда иметь под рукой спецификации и тестовые данные, когда работаешь в студии.
2) Считывание пользовательских типов данных.
Насколько просто в Fitnesse считать из спецификации данные такого вида?
$Vertices =
(0;0) (4;0) (4;3) (0;3)
(0;2) (2;2) (2;3) (0;3)
(0;1) (3;1) (3;3) (0;3)
Это коллекция точек в двумерном пространстве.
Мой движок заточен на расширяемость пользовательскими типами данных.
3) Ориентированность
Для тестирования в Fitness составляются таблицы. У меня же для каждого экземпляра тестовых данных пишется отдельная спецификация. Приблизительно это означает, что каждый ряд из таблицы Fitness разворачивается в спецификацию.
Это отличие продиктовано отношением к тестовым данным. У меня сложилось впечатление, что Fitnesse ориентирован на более низкоуровневое unit-тестирование. У меня же упор на интеграционное. Мне сложно объяснить без демонстрации кода. Скоро опубликую статью про мой движок, там покажу что я имею ввиду.
4) Чистота кода
Мой движок не требует объявлять место хранения для свойств в классе. Такого вида код не встречается (http://schuchert.wikispaces.com/FitNesse.Tutorials.1):
private int channel;
public void setChannel(int channel) {
this.channel = channel;
}
Такой код никому не интересен. Зачем писать служебный код? Он не решает задачу тестирования. В коде должны быть вычисления реальных значения свойств, а данные уже есть в спецификации.
5) Простой тестовый вывод
У меня простой движок, он не генерирует HTML отчеты. У него простой консольный вывод в котором указано все что требуется программисту для исправления ошибки. При тестировании из-под студии консольный вывод сохраняется в результатах прогона теста.
1) Отношение к тестовым данным.
Насколько я понял, тестовые данные всегда задаются в табличном виде. Несколько аргументов и несколько проверяемых критериев. Но что делать в Fitnesse когда тестовые данные — это целый файл? Логично именно файл передавать как данные, если тестируется конвертирование документа в другой формат, к примеру.
У меня тестовые данные находятся либо в самой спецификации, либо в отдельном файле. В обоих случаях файлы хранятся в DLL тестового проекта как Embedded Resource. Это позволяет:
— Включать интеграционные тесты вместе со всеми данными в систему контроля версий.
— Всегда иметь под рукой спецификации и тестовые данные, когда работаешь в студии.
2) Считывание пользовательских типов данных.
Насколько просто в Fitnesse считать из спецификации данные такого вида?
$Vertices =
(0;0) (4;0) (4;3) (0;3)
(0;2) (2;2) (2;3) (0;3)
(0;1) (3;1) (3;3) (0;3)
Это коллекция точек в двумерном пространстве.
Мой движок заточен на расширяемость пользовательскими типами данных.
3) Ориентированность
Для тестирования в Fitness составляются таблицы. У меня же для каждого экземпляра тестовых данных пишется отдельная спецификация. Приблизительно это означает, что каждый ряд из таблицы Fitness разворачивается в спецификацию.
Это отличие продиктовано отношением к тестовым данным. У меня сложилось впечатление, что Fitnesse ориентирован на более низкоуровневое unit-тестирование. У меня же упор на интеграционное. Мне сложно объяснить без демонстрации кода. Скоро опубликую статью про мой движок, там покажу что я имею ввиду.
4) Чистота кода
Мой движок не требует объявлять место хранения для свойств в классе. Такого вида код не встречается (http://schuchert.wikispaces.com/FitNesse.Tutorials.1):
private int channel;
public void setChannel(int channel) {
this.channel = channel;
}
Такой код никому не интересен. Зачем писать служебный код? Он не решает задачу тестирования. В коде должны быть вычисления реальных значения свойств, а данные уже есть в спецификации.
5) Простой тестовый вывод
У меня простой движок, он не генерирует HTML отчеты. У него простой консольный вывод в котором указано все что требуется программисту для исправления ошибки. При тестировании из-под студии консольный вывод сохраняется в результатах прогона теста.
Мой первоночальный комментарий — ни в коей мере не критика, просто хотел добавить что существуют готовые решения подобного рода. Я с удовольствием посмотрю на код вашего движка — Fit расширяем и мы постоянно этим пользуемся, адаптируя его для наших проектов. Возможно мы сможем позоимствовать интересные идеи и у вас :)
Исключительно для информации:
Таблица в Fit-тесте это просто метод задания данных. То, как эти данные интерпретируются, находиться полностью на усмотрении программиста. Мы используем таблица как непосредственно для передачи данных в тест, так и для задания пути к файлу, где эти данные можно получить. Это же относится и к пользовательским данным — все в руках пишущего спецификацию.
Fit-тест можно условно разделить на три части: html-спецификация, инфраструктурный код, использующий Fit-framework и собственно тестируемые классы. Инфраструктурный код интерпретирует получаемые данные, вызывает тестируемый код и возвращает результаты, в коде программы для поддержки Fit ничего менять не надо.
Основной метод отчота — html, но консольные утилиты Fit позволяют интерпретировать эти отчеты, выводить результаты на консоль и использовать Fit-тесты в автоматическом билде.
Исключительно для информации:
Таблица в Fit-тесте это просто метод задания данных. То, как эти данные интерпретируются, находиться полностью на усмотрении программиста. Мы используем таблица как непосредственно для передачи данных в тест, так и для задания пути к файлу, где эти данные можно получить. Это же относится и к пользовательским данным — все в руках пишущего спецификацию.
Fit-тест можно условно разделить на три части: html-спецификация, инфраструктурный код, использующий Fit-framework и собственно тестируемые классы. Инфраструктурный код интерпретирует получаемые данные, вызывает тестируемый код и возвращает результаты, в коде программы для поддержки Fit ничего менять не надо.
Основной метод отчота — html, но консольные утилиты Fit позволяют интерпретировать эти отчеты, выводить результаты на консоль и использовать Fit-тесты в автоматическом билде.
А как же нагрузочное тестирование?
Приведена классификация по критерию «степень изолированности кода». У меня это явно указано.
Классифицировать можно по разным критериям.
Классифицировать можно по разным критериям.
Институтский курс и жизнь — понятия несовместимые, как правило :-)
В своих проектах мы делаем нагрузочное тестирование, т.к. в требованиях четко прописаны тайминги и количество одновременных пользователей
Еще раз повторяю — нагрузочное тестирование из другой классификации.
en.wikipedia.org/wiki/Software_testing#Non_Functional_Software_Testing
Один и тот же тест можно отнести в разные группы по разным срезам классификаций. Нагрузочное тестирование, как правило, происходит либо при системном тестировании, либо при интеграционном.
en.wikipedia.org/wiki/Software_testing#Non_Functional_Software_Testing
Один и тот же тест можно отнести в разные группы по разным срезам классификаций. Нагрузочное тестирование, как правило, происходит либо при системном тестировании, либо при интеграционном.
М-да, сколько разработчиков, столько и определений разных видов тестов…
Лично мне (не будут претендовать на «самое лучшее определение») ближе примерно такая идея: Unit — это не отдельный класс, а *один или несколько* классов, выполняющих определенную задачу. Есть для этого понятие Component. При этом нас не должно интересовать, как общаются между собой классы внутри компоненты (компонента?), и мы это не тестируем. В результате, рефакторинг не обвалит наши тесты.
«Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.» Есть два подхода. Девелоперский, когда существующая (или планируемая) структура кода первична, а тесты пишутся «под нее». Тут мы будем иметь тестирование того *как* работает наша программа. И «Пользовательский» или «функциональный» подход, когда тесты пишутся, исходя из требований. И мы тестируем *что* делает наша программа.
Интеграционное тестирование (опять-таки, мое субъективное понимание этого термина) — проверка того, как наши компоненты работают вместе. Необязательно устраивать проверку всех возможных сочетаний входных данных, достаточно проверить основные. При этом все остальные компоненты, а также внешние зависимости, отсекаются мок-объектами. Или, например, используется тестовая база данных (типа in-memory SQLite).
Лично мне (не будут претендовать на «самое лучшее определение») ближе примерно такая идея: Unit — это не отдельный класс, а *один или несколько* классов, выполняющих определенную задачу. Есть для этого понятие Component. При этом нас не должно интересовать, как общаются между собой классы внутри компоненты (компонента?), и мы это не тестируем. В результате, рефакторинг не обвалит наши тесты.
«Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.» Есть два подхода. Девелоперский, когда существующая (или планируемая) структура кода первична, а тесты пишутся «под нее». Тут мы будем иметь тестирование того *как* работает наша программа. И «Пользовательский» или «функциональный» подход, когда тесты пишутся, исходя из требований. И мы тестируем *что* делает наша программа.
Интеграционное тестирование (опять-таки, мое субъективное понимание этого термина) — проверка того, как наши компоненты работают вместе. Необязательно устраивать проверку всех возможных сочетаний входных данных, достаточно проверить основные. При этом все остальные компоненты, а также внешние зависимости, отсекаются мок-объектами. Или, например, используется тестовая база данных (типа in-memory SQLite).
Sign up to leave a comment.
Виды тестирования и подходы к их применению