Сосредоточьтесь на тестировании самых рискованных элементов вашего кода. Под «рискованными элементами» я подразумеваю вещи, которые могут быть реализованы неправильно или не полностью или которые могут сломаться позже, когда вы сделаете другие изменения.
Один простой способ сказать, что вы должны тестировать, - это те части, где вы нажимаете «обновить» или «скомпилировать», просто чтобы посмотреть, что произойдет, и сделали ли вы это. Например, вы упомянули, что ваша система анализирует XML-файлы: возможно, вам нужен был широкий диапазон входных XML-файлов, чтобы убедиться, что все они работают, но если какой-то идеальный человек передаст вам код синтаксического анализа XML и скажет «это гарантированно сработает», вы вероятно, не осуществил бы или изучил бы вручную. Автоматизированное тестирование позволяет вам быть идеальным человеком или, по крайней мере, знать, когда ваш код с большой вероятностью будет работать. Кроме того, если вы обнаружите случай, когда эта система не работала , она позволяет вам написать тест, чтобы определить, работает ли ваша система в этом случае, и убедиться, что ваши изменения не вызывают сбой системы для любого из предыдущих тестов, которые вы написали.
К этому моменту вы будете лучшим экспертом в отношении того, какие части вашей системы являются наиболее рискованными, поэтому вы можете лучше всего написать тесты для снижения этого риска. Вам также может понадобиться реструктурировать свой код, чтобы он был достаточно гибким для тестирования, что может включать в себя отображение полей и методов видимыми или возможность замены соединения с базой данных в коде обработки вашей базы данных; это нормально и полезно, если позволяет вашей системе быть более тестируемой.
Модульные тесты хороши для небольших и автономных систем, а это значит, что они не обязательно хороши для всех частей вашего стека:
- подключиться к удаленному серверу через SFTP
Эта часть может быть трудна для модульного тестирования, потому что вы не обязательно хотите, чтобы ваш тест не прошел, если ваш компьютер отключен или SFTP-сервер не работает. Рекомендуется написать функциональный тест или интеграционный тест , чтобы убедиться, что ваша система продолжает работать с нужным SFTP-сервером.
Если вы хотите убедиться, что ваша система правильно интерпретирует вашу конфигурацию, чтобы отправил правильный запрос на правильный SFTP-сервер , это может быть хорошим модулем для тестирования, но будет гарантировать только то, что вы делаете правильный запрос, а не то, что он дает вам правильный ответ или поведение. Это может быть хорошим примером для макета фреймворка (издевательства над вашими вызовами FTP), но это страдает от той же проблемы: вы можете убедиться, что вы делаете ожидаемый запрос, но не получаете правильный ответ об этом.
- локально скопировать некоторые XML-файлы
Работа с файловой системой может быть сложной в модульных тестах, потому что вам нужно убедиться, что вы установили свои файлы во временный каталог или другое предсказуемое место, на которое не будут влиять реальные данные или предыдущие тесты. Однако это можно сделать: вы можете создать пример XML-файла, запустить код копирования и убедиться, что результат находится в ожидаемом месте.
Еще раз, вы можете использовать макеты или заглушки, чтобы убедиться, что вы делаете правильные вызовы к файловой системе, что может быть более предсказуемым, чем использование реальной файловой системы, но только гарантирует, что вы делаете ожидаемые вызовы, а не Вы получаете правильные результаты.
- парсит эти файлы
Это очень простой случай для модульного тестирования. Подготовьте или загрузите некоторые файлы примеров, запустите их через свой анализатор и убедитесь, что результат соответствует вашим ожиданиям.
- сохранить проанализированные данные в базе данных
Эту часть также легко протестировать, если она трудоемка: вы можете взять пример данных, которые вы проанализировали, отправить их в вашу систему, а затем прочитать базу данных, чтобы убедиться, что фрагменты находятся там, как вы ожидаете.Сложность может заключаться в том, что ваша база данных настроена аналогично рабочей, но без использования реальной производственной базы данных;Возможно, вы захотите использовать базу данных в памяти.
Опять же, у вас есть возможность просто проверить, что команды базы данных точны: вы можете решить, что этого достаточно, чтобы убедиться, что вы используете правильный запрос справильные параметры.Однако использование реального движка базы данных даст вам более тщательный тест, гарантирующий, что команда выполнена успешно, что она проходит все правила проверки базы данных относительно обязательных полей или форматов, и что она не усекает и не удаляет символы или точность чисел.
Интеграционный тест может гарантировать, что для данного XML-файла он корректно пробирается к базе данных;однако такой тест, скорее всего, будет медленнее, и в случае его неудачи вам, возможно, придется проделать дополнительную работу, чтобы выяснить, какой блок вышел из строя.Следовательно, вам, вероятно, следует подумать о всесторонних модульных тестах как можно скорее и сосредоточиться на интеграции и сквозных тестах позже.
См. Также: Are (база данных)тесты интеграции плохие? , связанный вопрос, на который я отвечал на Software Engineering Stack Exchange