Нямам конкретен проект, който да чака TDD
Харесва ми концепцията колкото се може повече функции да се тестват без хардуер, и ТДД е стъпка в тази посока, т.е. изглежда, че трябва да се пише повече хардуерно-агностичен код, за да може да се тества.
| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| Test Driven Development http://mcu-bg.com/mcu_site/viewtopic.php?f=7&t=18456 |
Страница 1 от 1 |
| Автор: | stewie [ Пон Юли 18, 2022 11:41 am ] |
| Заглавие: | Test Driven Development |
Някой да е запознат с TDD за ембедед? От доста хора из нета се чуват позитиви за тестовете като цяло. Аз нямам никакви off-target тестове, да си призная, и искам да се понауча да тествам поне част от кода на ПЦ. Ето малко хвалби за ТДД: https://embeddedartistry.com/blog/2018/ ... dd-course/ |
|
| Автор: | gicho [ Пон Юли 18, 2022 5:53 pm ] |
| Заглавие: | Re: Test Driven Development |
Какво те интересува? Концепцията е много правилна, но си иска ресурс (време, хора, пари). За ембеддед - още повече. |
|
| Автор: | stewie [ Пон Юли 18, 2022 7:01 pm ] |
| Заглавие: | Re: Test Driven Development |
Интересува ме някой прилага ли го в ембедед. Захванал съм да чета книгата https://www.amazon.com/Driven-Developme ... 193435662X, харесва ми идеята и искам да чуя мнения от хора, които са по-навътре в нещата от едно четене на книга. Казват, че първоначалната инвестиция се изплаща. |
|
| Автор: | gicho [ Пон Юли 18, 2022 10:01 pm ] |
| Заглавие: | Re: Test Driven Development |
За какъв по размер и организация проект говорим? |
|
| Автор: | stewie [ Сря Юли 20, 2022 11:15 am ] |
| Заглавие: | Re: Test Driven Development |
Нямам конкретен проект, който да чака TDD Харесва ми концепцията колкото се може повече функции да се тестват без хардуер, и ТДД е стъпка в тази посока, т.е. изглежда, че трябва да се пише повече хардуерно-агностичен код, за да може да се тества. |
|
| Автор: | gicho [ Чет Юли 21, 2022 3:11 pm ] |
| Заглавие: | Re: Test Driven Development |
Да, тестването без хардуер не опира само до "тестването" - имам предвид че има концепции как се пише код, който е подходящ за тестване. Изолиран от зависимостите си и разцепен на дребни части - това е началото. |
|
| Автор: | HCL [ Пон Юли 25, 2022 11:20 pm ] |
| Заглавие: | Re: Test Driven Development |
Мога да споделя опит от гледна точка на хардуерния TDD. Т.е. как правим чиповете така, че сами да си търсят и намират грешките. От там нататък можеш да направиш паралели с embedded SW. Като цяло концепцията е изградена върху три опори: 1. Bilt-in self test (BIST) - тук вграждаме малко логика която да тества дадена функционална единица. Най-тривиалният пример е малък FSM, който да пише и чете различни pattern-и в паметта и да проверява дали прочетеното отговаря на написаното. Алтернативен пример е функция, която смята CRC на поток от данни и го прекрепя към него, преди този да бъде изпратен по комуникационнен интерфейс. От другата страна същата функция се очаква да върне същия резултат. Ако няма съвпадение значи данните са били повредени при трансфера. 2. Assertions - това трябва да ти е навик. Когато пишеш дадена функция, една част от мозъка ти винаги трябва да е заета да мисли какви стойности или комбинации от стойности са невъзможни. Съотввтно правиш проверка и ако ги видиш биеш аларма. Добра практика е да го прилагаш и на системно ниво. Примерно ако алгоритмите ти сатурират на дадена стойност, можеш да правиш проверки за нарушение на обхвата и разделителна способност. Sutherland има добра статия по темата https://sutherland-hdl.com/papers/2015- ... _paper.pdf 3. micro test bench - тестваш всички функции на най-ниско ниво, още преди да напишеш интеграционните и системни тестове. Идеята е малко bottom-up, вместо рапространеното top-down. На пръв поглед отнема повече време, но който е дебъгвал сложни системи знае, че това е само привидно. 2/3 от времето отива в тестване и 1/3 в развой. И тъй като често работата се върши от различни екипи 1/2 към 1/2 е далеч по-ефективно. |
|
| Автор: | emilvtc [ Вто Юли 26, 2022 12:46 am ] |
| Заглавие: | Re: Test Driven Development |
За ембедед ми изглежда много трудно приложимо. Освен тестването на логиката на отделни функции, изпълнението на програмата като цяло в една реална система с RTOS е много зависима и от това коя функция за колко време и в кой момент се изпълнява. Колко често и какви прекъсвания заемат процесорният ресурс за да обслужват хардуера / драйверите за него и т.н. И на мен ще ми е интересно да видя нещо такова за реално приложение. |
|
| Автор: | HCL [ Вто Юли 26, 2022 12:27 pm ] |
| Заглавие: | Re: Test Driven Development |
Да, това е една от отявлените разлики между хардуерното и софтуерното решение. При хардуерът, можем с малко допълнителна логика да направим тестовете да вървят паралелно на функционалните изчисления, което ги прави non-ivasive. При софтуерът опирате до time sharing на хардуерни ресурси, който пак би могъл да бъде транспарентен, но това изисква внимателно планиране на scheduling-а с всичките му неприятни ефекти от гледна точка на скалируемост на ресурсите в бъдеще. Но чисто теоретично, всяка една система може да бъде планирана така, че един процент от ресурсите да бъде заделен за тестване без това да нарушава нейният времеви детерминизъм. Това е един от основните аргументи в полза на time slot scheduled RTOS. И въпреки това бих предполжил, че >90% от всички ембедед системи в днешно време са базирани на прекъсвания с много примитивни scheduler-и, чиите недъзи биват компенсирани с повече изчислителна мощност... |
|
| Автор: | stewie [ Сря Авг 10, 2022 1:30 pm ] |
| Заглавие: | Re: Test Driven Development |
@HCL - благодаря за детайлния пример. Относно assertions, ползвам ги доста, следвайки концепцията Design by Contract. Хаващат ми доста от бъговете. Някой да има опит с интегриране на CppUTest в STM32CubeIDE? Искам тестовете да се билдват с gcc за десктоп, а самият проект с arm-none-eabi-gcc. |
|
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|