Comments 8
В данном случае мы создали имитацию кнопки
Вообще-то в этом-то и заключается основная проблема тестов ПО для МК — вы должны имитировать железо полностью, со всеми сопутствующими эффектами, типа дребезга контактов и т.д. Если писать имитаторы для этого — можно замучаться и поэтому часто железное тестирование предпочитают софтверному.
Но вот с автоматизацией железного тестирования проблема стоит уже совсем в другой области.
Я не профессиональный программист. Несколько раз пытался понять, что же такое — тесты, но безуспешно. Из статьи получается, что программист должен вообразить и прописать все возможные и невозможные ошибочные сценарии, но как??? Они же ошибочные, а стал быть, при программировании о них даже не думаешь, а если думаешь, то уже не такие они и ошибочные…
По идее правильные тесты должен писать не тот, кто написал код, а другой человек. Тогда результат обычно превосходит ожидания.
Вы пишете тесты с корректными входными данными, в них проверяете что результат требуемый. Также, вы пишете тесты с невалидными входными данными, и в них проверяете, что программа не упала и корректно залогировала ошибку, например.
Как придумать с какими данными запускать вашу программу? Об это суть есть наука о тестировании ПО. Там придумали ряд методик и подходов, позволяющих с одной стороны покрыть всевозможные граничные случаи, а с другой стороны не наплодить миллион тестов.
Гарантирует ли это то, что вы покроете все возможные ошибочные сценарии и в продакшене ошибки не произойдет? Конечно же нет. И конечно же всё зависит от вашего опыта.
Как приблизиться к идеальному результату? Изучать тестирование. Практиковаться в написании тестов. Ну и писать новые тесты на те баги, которые у вас нашлись в продакшене.
Главная ценность модульных тестов в том, что вы автоматизируете регрессионное тестирование, а это значит, что вы сможете быстрее выкатывать релизы, и не бояться менять существующий код, например для рефакторинга.
Ceedling + Eclipse или unit-тесты для микроконтроллеров