Как стать автором
Обновить

Ceedling + Eclipse или unit-тесты для микроконтроллеров

Время на прочтение 2 мин
Количество просмотров 9.6K
Всего голосов 17: ↑16 и ↓1 +15
Комментарии 8

Комментарии 8

В данном случае мы создали имитацию кнопки

Вообще-то в этом-то и заключается основная проблема тестов ПО для МК — вы должны имитировать железо полностью, со всеми сопутствующими эффектами, типа дребезга контактов и т.д. Если писать имитаторы для этого — можно замучаться и поэтому часто железное тестирование предпочитают софтверному.


Но вот с автоматизацией железного тестирования проблема стоит уже совсем в другой области.

Причем на эту самую имитацию тоже нужно написать тест.

Угу. Причем часто этот тест — это инструкция для людей, а не для процессоров, что многократно усложняет задачу. :)

Я не профессиональный программист. Несколько раз пытался понять, что же такое — тесты, но безуспешно. Из статьи получается, что программист должен вообразить и прописать все возможные и невозможные ошибочные сценарии, но как??? Они же ошибочные, а стал быть, при программировании о них даже не думаешь, а если думаешь, то уже не такие они и ошибочные…

По идее правильные тесты должен писать не тот, кто написал код, а другой человек. Тогда результат обычно превосходит ожидания.

Немного не так. Вы пишете программу, которая должна выдавать требуемый результат, при правильных входных данных. А также, должна коректно обрабатывать ошибочные входные данные.

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

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

Гарантирует ли это то, что вы покроете все возможные ошибочные сценарии и в продакшене ошибки не произойдет? Конечно же нет. И конечно же всё зависит от вашего опыта.

Как приблизиться к идеальному результату? Изучать тестирование. Практиковаться в написании тестов. Ну и писать новые тесты на те баги, которые у вас нашлись в продакшене.

Главная ценность модульных тестов в том, что вы автоматизируете регрессионное тестирование, а это значит, что вы сможете быстрее выкатывать релизы, и не бояться менять существующий код, например для рефакторинга.
НЛО прилетело и опубликовало эту надпись здесь
Мне когда-то на тему модульного тестирования для embedded очень понравилась вот эта книга: Test Driven Development for Embedded C by James W. Grenning. В целом, тестировать какие-то инкапсулироавнные модули при наличии нормального HAL вполне возможно. А вот если речь идёт об управлении каким-то физическим процессом в реальном времени, причём алгоритм работает по прерываниям от нескольких разных аппаратных блоков, то тут уже сложнее. Хотя всё-равно можно, например, проверить математику на предмет корректности и каких-нибудь целочисленных переполнений.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории