Jump to content

    
Sign in to follow this  
Муравей

Как тестировать код для встраиваемых систем

Recommended Posts

Это типа программист который реализует код или кто?

Да, юнит-тесты пишет программист. Можно использовать того, который пишет и код, можно другого.

 

Вы конкретно писали юнит тесты? К коду который так-же сами и написали? Или как?

Да, писал. К коду, который сам же и написал.

 

Суть юнит-тестов не в какой-то бюрократии или 100% покрытии, а в подготовке кода к рефакторингу. Юнит-тестирование позволяет уменьшить вероятность, что что-то сломается при рефакторинге, а также предполагает переработку архитектуры кода в плане тестируемости. Эта переработка архитектуры подготавливает код к дальнейшему изменению, т.е. при добавлении новой фичи меньше вероятность, что придётся всё раскурочивать.

Share this post


Link to post
Share on other sites
...Можно использовать того, который пишет и код...Суть юнит-тестов ...

в подготовке кода к рефакторингу. Юнит-тестирование позволяет уменьшить вероятность, что что-то сломается при рефакторинге,

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

т.е. при добавлении новой фичи меньше вероятность, что придётся всё раскурочивать.

 

Замечательно..

Ну а теперь посмотрите о чём велась речь выше:

 

Цитата(kolobok0): "в том виде котором юзают юнит тесты они проверяют только изменение кода со временем. И больше ничего."

 

Цитата(vanner): "первая задача модульного тестирования - это проверка корректности работы функции (модуля), т.е.

проверка условия что при указаных входных данных получается корректный результат и/или корректная обработка ошибки.

Проверка регрессий это уже побочный эффект по-сути, при наличии ранее работоспособных тестов легко определить какое

изменение сломало модуль. "

(извините за полное цитирование)

 

Так, что уважаемый andrewlekar - наши с вами восприятия нахрена это нужно - имеют один вектор.

А вот господин vanner ожидает(насколько я его смог понять) = "проверка корректности работы функции" .

 

Я заострил внимание именно на организационном моменте. Т.к. именно он определяет качество самих тестов в

плане "корректности работы функции".

Объясняю:

Лично мне слабо понимается сам процесс написания кода программистом, и написание тестов к нему этим-же программистом.

Тесты в этом случае могут НЕ ВЫЯВИТЬ "некорректности работы функции". Т.е. вряд ли правая рука сможе

написать такого, что упустит в реализации левая. А левая вряд ли будет тестировать то, что НЕ написала(либо не знала) правая

рука одного и того-же человека.

 

Надеюсь мысль передал.

Остаётся только всё то вспомогательное которое не имеет отношения к качеству и уменьшению затрат при производстве

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

и уйдёт с ошибкой дальше....

 

ЗЫ

Забегая вперёд, отвечу - я не против механики. Я считаю, что метода хромает. Метода, которая увы и ах применяется повсеместно (противного

не наблюдал). Т.е. написал человек код, написал к нему тест... А как деление на ноль было так и осталось. Вряд-ли человек напишет проверку

выше по уровню знаний чем его же написанный код, который он тестирует.

 

Share this post


Link to post
Share on other sites
Объясняю:

Лично мне слабо понимается сам процесс написания кода программистом, и написание тестов к нему этим-же программистом.

Тесты в этом случае могут НЕ ВЫЯВИТЬ "некорректности работы функции". Т.е. вряд ли правая рука сможе

написать такого, что упустит в реализации левая. А левая вряд ли будет тестировать то, что НЕ написала(либо не знала) правая

рука одного и того-же человека.

 

Надеюсь мысль передал.

 

Да, абсолютно понятна ваша мысль, вы совершенно не занимаетесь проектированием своего ПО. Конечно трудно протестировать спаггети-код который делает несколько функций сразу, да еще программист пишет одной рукой ;) В общем, читайте книги, практикуйтесь, со временем все придет :)

 

Share this post


Link to post
Share on other sites
Да, абсолютно понятна ваша мысль, вы совершенно не занимаетесь проектированием своего ПО. Конечно трудно протестировать спаггети-код который делает несколько функций сразу, да еще программист пишет одной рукой ;) В общем, читайте книги, практикуйтесь, со временем все придет :)

 

А пример реальной функции которую вы подвергали юнит-тестированию можете дать?

 

Я расшифровываю понятие юнит-тестирование как тестирование элементарных функций (unit - единица, элемент)

Зачем нужно тестировать элементраные функции охватываемы взглядом, вроде таких: с = a + b, если вы в своем уме и доверяете глазам ?

 

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

Это свойственно C++ с переопределением операций, шаблонами и прочими фичами, и больше актульно программистам на PC которые пишут код не комприлируемый напрямую в ассемблер или базирующийся на объектных библиотеках представляющих собой черный ящик.

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

 

На нормальном C-и, раз взглянув на элементарную функцию и мысленно помоделировав ее выполнение можно дальше ее не тестировать.

Если же мысленно не тестируется, как например файловая система, то юнит-тестирование здесь ну никак не поможет и не встроится, надо писать макротестирование, делать логи, профилировать, проходить по шагам и только на целевой платформе.

 

 

Share this post


Link to post
Share on other sites

Юнит тестирование применяется в больших иерархических проектах.

 

Очень сложно оценить по очертаниям развалин, из за какого именно кирпича в подвале рухнул дом. Лучше кирпичи тестировать отдельно :)

 

Share this post


Link to post
Share on other sites
Очень сложно оценить по очертаниям развалин, из за какого именно кирпича в подвале рухнул дом. Лучше кирпичи тестировать отдельно :)

 

Если каждый кирпич тестировать на прочность, это автоматически приведет к уменьшению их ресурса. Соответсвенно и дом будет менее прочным.

И зачем искать виноватый кирпич если они все одинаковые?

Share this post


Link to post
Share on other sites
И зачем искать виноватый кирпич если они все одинаковые?
Если они одинаковые, то и тестировать надо 1 кирпич (и не тот, который потом пойдет в фундамент дома). Так же надо тестировать и все остальное - не из одних же кирпичей дом строят :rolleyes:

 

Share this post


Link to post
Share on other sites
Если они одинаковые, то и тестировать надо 1 кирпич (и не тот, который потом пойдет в фундамент дома). Так же надо тестировать и все остальное - не из одних же кирпичей дом строят :rolleyes:

Ну тогда дом будет построен из обломков. :biggrin:

Share this post


Link to post
Share on other sites
Ну тогда дом будет построен из обломков. :biggrin:
Угу. Видел я некоторые системы, так они были построены даже не из обломков, а скорее из щебенки :maniac:

в принципе при наличии нормальной системы тестирования продукта в целом, unit тесты уже как бы и не обязательны - баги будут пойманы все равно, но если интересует не факт наличия багов, а работающая целая система, то unit тесты - как говорится must have (или отладка такой системы может превратится в кошмар) :rolleyes:

 

Share this post


Link to post
Share on other sites
Угу. Видел я некоторые системы, так они были построены даже не из обломков, а скорее из щебенки :maniac:

в принципе при наличии нормальной системы тестирования продукта в целом, unit тесты уже как бы и не обязательны - баги будут пойманы все равно, но если интересует не факт наличия багов, а работающая целая система, то unit тесты - как говорится must have (или отладка такой системы может превратится в кошмар) :rolleyes:

Ну так вот, в жизни, как известно, никто не тестирует ни кирпичи ни панели (просто напротив сейчас как раз кирпичный дом строят :biggrin: и я вижу весь тех процесс ) ни прочие детали.

Тесты убивают время и ресурсы, юнит-тесты особенно.

Стандартный подход - сначала построить, потом чинить. Все силы на облегчение ремонта и замены. ;)

 

 

 

Share this post


Link to post
Share on other sites
качество самих тестов.

Это один из моментов зачем нужен TDD. Тест может содержать ошибку. Для проверки что сам тест правильный, он выполняется два раза - до написания кода (тест должен вернуть ошибку), и после.

Share this post


Link to post
Share on other sites
...проверки что сам тест правильный, ...до написания кода (тест должен вернуть ошибку)...

 

Ваш пример показывает, что тест охватывает сам интерфейс, а не реализацию.

пример:

 

берём класс строка, который может содержать в себе и ноль так-же (ну например: стандартный CString от MFC).

Не всякий программист, обрабатывая строки это может осязать. Как следствие - режутся данные до нулевого символа.

 

Это как один из множества, и... "лёгкий" пример.

Поверьте мне дураку - таких нюансов очень и очень много.

Share this post


Link to post
Share on other sites
берём класс строка, который может содержать в себе и ноль так-же (ну например: стандартный CString от MFC).

Не всякий программист, обрабатывая строки это может осязать. Как следствие - режутся данные до нулевого символа.

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

 

тест охватывает сам интерфейс, а не реализацию.

Не, ну как - на каждый нюанс поведения функции свой тест.

Share this post


Link to post
Share on other sites
Вы про то, что программист может забыть написать обработку такого варианта? Да, если забыл один кейс, то сто других тестов на сто других кейсов тут не помогут.

Не, ну как - на каждый нюанс поведения функции свой тест.

Это все похоже не про встраиваемые системы.

 

А вот сегодня пришло из рассылки barrgroup: http://www.edn.com/design/automotive/44234...ts-consequences

Очень поучительная история про ошибку в систему управления TOYOTA которая привела к фатальным последствиям.

 

Эксперты по программному обеспечению NASA оказались бессильны (видать юнит-тесты пытались применить)

А в реальности это наименее важный момент.

Самое опасное это Single points of failure (SPOF), обнаружить которые не поможет ни один юнит-тест. Еще очень опасен программно-аппаратный симбиоз багов.

Вторая показательная ошибка - тестирование в отрыве от платформы. Переполнение стека RTOS ну очень сложно заметить моделируя софт на PC (чем наверно и занималось NASA) .

 

Есть там и интересные рекомендации по организации тестирования.

 

Интересна отсылка к оценке параметра под названием Cyclomatic complexity, как предсказателю количества ошибок.

Странно но в популярных IDE такой фичи не встречал.

Share this post


Link to post
Share on other sites
Это все похоже не про встраиваемые системы.

Первая книжка про TDD, которую я прочитал и начал применять - именно "Test Driven Development for Embedded C".

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

 

 

А, вы не не про логику. Да, юнит тесты это про логику. Переполнения стека, утечки памяти - они не для этого.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this