Оч. понравилась, конечно, идея разработки с тестами... Вот только уже давно не могу понять. Допустим есть у меня метод, который отсылает почту нескольким джентельменам, адреса которых берет из базы. Как писать тест? Не могу же я их почтовые ящики проверить. Дошло или нет.
Или допустим мой метод анализирует файлы по указанному пути... на выходе дает некоторую сумму. Файлы, допустим вперемешку ворд и эксель с жуткой структурой. Тоже непонятно как тестировать. Если копировать на локальный диск, в папку проекта, так нельзя распространять файлы эти... запрещено внутренними политиками и т.п.

Здравствуйте, Ellin, Вы писали:

E>Оч. понравилась, конечно, идея разработки с тестами... Вот только уже давно не могу понять. Допустим есть у меня метод, который отсылает почту нескольким джентельменам, адреса которых берет из базы. Как писать тест? Не могу же я их почтовые ящики проверить. Дошло или нет.
E>Или допустим мой метод анализирует файлы по указанному пути... на выходе дает некоторую сумму. Файлы, допустим вперемешку ворд и эксель с жуткой структурой. Тоже непонятно как тестировать. Если копировать на локальный диск, в папку проекта, так нельзя распространять файлы эти... запрещено внутренними политиками и т.п.

Правильный дизайн, заглушки и эмуляторы.

Вообще вечная тема, довольно часто обсуждается...

Здравствуйте, Ellin, Вы писали:

Вы допускаете наиболее распространённую ошибку начинающего использовать тесты.

E>Оч. понравилась, конечно, идея разработки с тестами... Вот только уже давно не могу понять. Допустим есть у меня метод, который отсылает почту нескольким джентельменам, адреса которых берет из базы. Как писать тест? Не могу же я их почтовые ящики проверить. Дошло или нет.
То, что вы говорите ("дошло или нет?") — это интеграционный тест. Юнит-тест здесь должен проверять, что на все адреса, которые он взял (из мока), вызван соответствующий метод сервиса, отвечающего за отправку писем...

E>Или допустим мой метод анализирует файлы по указанному пути... на выходе дает некоторую сумму. Файлы, допустим вперемешку ворд и эксель с жуткой структурой. Тоже непонятно как тестировать. Если копировать на локальный диск, в папку проекта, так нельзя распространять файлы эти... запрещено внутренними политиками и т.п.
Опять интеграционный тест. Во-первых, можно сварганить тестовые данные, во-вторых, можно эмулировать их содержимое.
Вообще главное правило тут — юнит-тест должен тестировать _один_ метод, при этом все его зависимости должны быть сымитированы моками

Здравствуйте, koandrew, Вы писали:

E>>Или допустим мой метод анализирует файлы по указанному пути... на выходе дает некоторую сумму. Файлы, допустим вперемешку ворд и эксель с жуткой структурой. Тоже непонятно как тестировать. Если копировать на локальный диск, в папку проекта, так нельзя распространять файлы эти... запрещено внутренними политиками и т.п.
K>Опять интеграционный тест. Во-первых, можно сварганить тестовые данные, во-вторых, можно эмулировать их содержимое.
K>Вообще главное правило тут — юнит-тест должен тестировать _один_ метод, при этом все его зависимости должны быть сымитированы моками
Вот здесь в том то и проблема, что эмулировать эти данные раз в 5 ато и больше более трудоемко, чем сама разработка...

Здравствуйте, Ellin, Вы писали:

E>Вот здесь в том то и проблема, что эмулировать эти данные раз в 5 ато и больше более трудоемко, чем сама разработка...

А кто сказал, что юнит-тесты это просто? В каждой задаче применим свой подход тестирования.

Здравствуйте, Ellin, Вы писали:

E>Вот здесь в том то и проблема, что эмулировать эти данные раз в 5 ато и больше более трудоемко, чем сама разработка...

Это необычно, но нормально. А как собственно еще писать гарантированно работающий код? За счет уверенности в себе и метода пристального взгляда?..

К тому же, я не уверен, что эмулировать данные так сложно: код возможно и будет больше, а вот трудоемкость едва ли. Во-первых есть библиотеки, помогающие эмулировать(тот же NMock), во-вторых выручает проектирование, особенно IoC, в-третьих выручает то, что эмулировать не обязательно программно, напротив лучше эмулировать физически: просто хранить объекты заранее сохраненными в нужных состояниях и использовать их.

Здравствуйте, Nuseraro, Вы писали:

N>Здравствуйте, Ellin, Вы писали:

E>>Вот здесь в том то и проблема, что эмулировать эти данные раз в 5 ато и больше более трудоемко, чем сама разработка...

N>Это необычно, но нормально. А как собственно еще писать гарантированно работающий код? За счет уверенности в себе и метода пристального взгляда?..

N>К тому же, я не уверен, что эмулировать данные так сложно: код возможно и будет больше, а вот трудоемкость едва ли. Во-первых есть библиотеки, помогающие эмулировать(тот же NMock), во-вторых выручает проектирование, особенно IoC, в-третьих выручает то, что эмулировать не обязательно программно, напротив лучше эмулировать физически: просто хранить объекты заранее сохраненными в нужных состояниях и использовать их.
Хорошо. Например, метод возвращает список сотрудников организации. Нужно делать локальную базу данных с тестовыми записями? (ведь наша тестовая база может меняться другими программерами, другими модулями.)

Здравствуйте, Ellin, Вы писали:

E>Хорошо. Например, метод возвращает список сотрудников организации. Нужно делать локальную базу данных с тестовыми записями? (ведь наша тестовая база может меняться другими программерами, другими модулями.)

Я юнит тесты прогоняю на локальной (разработческой) БД. Она в принципе почти соответствует базе на продакшене. В некоторых сиутациях такой подход может в полне подойти. Для меня к примеру подходит.
Или можете сначала добавить данные, считать их и провериьт в тесте, а затем удалить. Можно это все в одной транзакции для простоты сделать.

Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте, Ellin, Вы писали:

E>>Хорошо. Например, метод возвращает список сотрудников организации. Нужно делать локальную базу данных с тестовыми записями? (ведь наша тестовая база может меняться другими программерами, другими модулями.)

MC>Я юнит тесты прогоняю на локальной (разработческой) БД. Она в принципе почти соответствует базе на продакшене. В некоторых сиутациях такой подход может в полне подойти. Для меня к примеру подходит.
MC>Или можете сначала добавить данные, считать их и провериьт в тесте, а затем удалить. Можно это все в одной транзакции для простоты сделать.

В условиях сферического вакуума считается, что у Вас нет прямого доступа к базе — он делегируется через сущности data access layer. Соответственно, нужен мок-объект, который с помощью коллекции предопределенных данных будет эмулировать таблицу БД, и отсылка письма "превед, сатруднеги!" должна просто обратиться к некоему абстрактному сервису из data access layer, который и выплюнет необходимую коллекцию (или енумератор на неё, или еще что). Т.е. юнит-тест будет работать с мок-заглушкой, а реальное приложение — с реальной оберткой вокруг СУБД-движка.

Здравствуйте, Аноним, Вы писали:

А>В условиях сферического вакуума считается, что у Вас нет прямого доступа к базе — он делегируется через сущности data access layer. Соответственно, нужен мок-объект, который с помощью коллекции предопределенных данных будет эмулировать таблицу БД, и отсылка письма "превед, сатруднеги!" должна просто обратиться к некоему абстрактному сервису из data access layer, который и выплюнет необходимую коллекцию (или енумератор на неё, или еще что). Т.е. юнит-тест будет работать с мок-заглушкой, а реальное приложение — с реальной оберткой вокруг СУБД-движка.

Я привел пример когда юнит-тест тестирует именно DAL-метод.

Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте, Ellin, Вы писали:

E>>Хорошо. Например, метод возвращает список сотрудников организации. Нужно делать локальную базу данных с тестовыми записями? (ведь наша тестовая база может меняться другими программерами, другими модулями.)

MC>Я юнит тесты прогоняю на локальной (разработческой) БД. Она в принципе почти соответствует базе на продакшене. В некоторых сиутациях такой подход может в полне подойти. Для меня к примеру подходит.
MC>Или можете сначала добавить данные, считать их и провериьт в тесте, а затем удалить. Можно это все в одной транзакции для простоты сделать.

Только это не unit-тест, как бы тебе не хотелось обратного

Здравствуйте, gandjustas, Вы писали:

MC>>Я юнит тесты прогоняю на локальной (разработческой) БД. Она в принципе почти соответствует базе на продакшене. В некоторых сиутациях такой подход может в полне подойти. Для меня к примеру подходит.
MC>>Или можете сначала добавить данные, считать их и провериьт в тесте, а затем удалить. Можно это все в одной транзакции для простоты сделать.

G>Только это не unit-тест, как бы тебе не хотелось обратного

Это смотря что тестировать. Если я тестирую логику в какой-то функции, где используется БД, то да, тут можно сказать что есть зависимость от БД. Но если я тестирую DAL-метод который просто делает запрос в БД, то мне как раз нужно проверить корреткность выполнения этого запроса — и это будет именно именно unit-test соответствующего DAL-метода.

Здравствуйте, Ellin, Вы писали:

E>Оч. понравилась, конечно, идея разработки с тестами... Вот только уже давно не могу понять. Допустим есть у меня метод, который отсылает почту нескольким джентельменам, адреса которых берет из базы. Как писать тест? Не могу же я их почтовые ящики проверить. Дошло или нет.
E>Или допустим мой метод анализирует файлы по указанному пути... на выходе дает некоторую сумму. Файлы, допустим вперемешку ворд и эксель с жуткой структурой. Тоже непонятно как тестировать. Если копировать на локальный диск, в папку проекта, так нельзя распространять файлы эти... запрещено внутренними политиками и т.п.

Юнит-тесты — это глобальное зло.

Вот как можно оттестировать, отработал ли Javascript, который меняет стиль у кнопки, кладёт в hidden-поле какое-то значение?
Как можно определить, сохранилась информация в базе или insert сохранил информацию неправильно?
Как же так?

Юнит-тестирование — это всего лишь попытка эмуляции ситуаций развития событий, но никак не попытка устранить ошибки в системе.

P>Юнит-тесты — это глобальное зло.
Почему? Что предлагается взамен?

Здравствуйте, Ellin, Вы писали:

E>Оч. понравилась, конечно, идея разработки с тестами... Вот только уже давно не могу понять. Допустим есть у меня метод, который отсылает почту нескольким джентельменам, адреса которых берет из базы. Как писать тест? Не могу же я их почтовые ящики проверить. Дошло или нет.
E>Или допустим мой метод анализирует файлы по указанному пути... на выходе дает некоторую сумму. Файлы, допустим вперемешку ворд и эксель с жуткой структурой. Тоже непонятно как тестировать. Если копировать на локальный диск, в папку проекта, так нельзя распространять файлы эти... запрещено внутренними политиками и т.п.

Посмотри на typemock.net, он позволит тебе прозрачно для твоего кода, тоесть не меняя его вообще изолировать от внешней среды.
На самом деле их решение является для рынка революционным и пока я не видел аналогов.

Здравствуйте, Tom, Вы писали:

P>>Юнит-тесты — это глобальное зло.
Tom>Почему?

Потому что стоимость разработки и поддержки этих юнит-тестов иногда даже больше, чем 50% стоимости проекта.

Tom>Что предлагается взамен?

Полуручное тестирование (желательно большим числом людей).
Это простое, дешевое и надёжное средство.

Здравствуйте, Ellin, Вы писали:

E>Хорошо. Например, метод возвращает список сотрудников организации. Нужно делать локальную базу данных с тестовыми записями? (ведь наша тестовая база может меняться другими программерами, другими модулями.)

Если все, что функция делает, это возвращает список сотрудников организации(а так и должно быть), то на уровне unit-тестов я бы её не тестировал вовсе.

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

Здравствуйте, ppvrt, Вы писали:

P>>>Юнит-тесты — это глобальное зло.
P>Потому что стоимость разработки и поддержки этих юнит-тестов иногда даже больше, чем 50% стоимости проекта.

Во сколько % оцените стоимость тестирования и отладки ошибок в связи с изменениями в проектах без юнит-тестов и того же качества?

Здравствуйте, ppvrt, Вы писали:

Tom>>Что предлагается взамен?

P>Полуручное тестирование (желательно большим числом людей).
P>Это простое, дешевое и надёжное средство.

Большое число людей это просто дешево и надежно?
Не хватает еще термина "быстро"

P>Потому что стоимость разработки и поддержки этих юнит-тестов иногда даже больше, чем 50% стоимости проекта.
Мне кажется ты неправильно считаешь деньги. лучше посчитать какое количество денег и времени они экономят

P>Полуручное тестирование (желательно большим числом людей).
Это пять, без коментариев даже.

ЗЫ:
Вообще у нас в проекте наибольшую эффективность показали именно интеграционные тесты. Когда код не пытаются изолировать, ну или изолируют но минимально.
В юнит тестах я вообще не помню что бы мы нашли какие то баги а в интеграционных — постоянно.