Так и задачи у устройств на микроконтроллерах обычно другие, где красивые окошки рисовать не самое важное.
Но насчёт отставания вы правы, по крайней мере в культуре разработки софта разница очень заметна. Из моего опыта редкий программист встраиваемых систем пользуется системами контроля версий, например. А за всякие SOLID, паттерны и интерфейсы вообще можно хипстером-выпендрёжником прослыть. Хотя конечно может это мне просто не везёт так.
А упомянутые вами авторы занимаются проблемами командного программирования
Ага, особенно Греннинг.
Послушайте, я уже понял что ваше мнение относительно юнит-тестирования (и полагаю не только его) заключается в том что вы умнее всех. На фоне этого любые попытки объяснить вам тему разбиваются о ваш огромный опыт. Вы не задаёте вопросы, вы требуете объяснений «почему вы делаете так глупо, правильно же вот так». Когда вам указывают на некорректность или бессмысленность вопроса — вы реагируете в стиле «не отвечаешь — значит не можешь, шах и мат».
Искренне надеюсь что нам никогда не придётся работать вместе. Всего доброго.
Ох как неловко вышло… Надо пойти всем рассказать, а то тысячи и миллионы глупцов называют юнит-моделирование юнит-тестированием и даже не догадываются! Спасибо за вашу мудрость.
устроенный автором процесс минимум в два раза усложняет изменения
Вы этот вывод сделали из того что кода больше писать? Ну да, действительно. Вот бы у меня тоже сложность программирования зависела только от скорости печати. Восхищён вами.
считаю что юнит-тестировать такие функции GUI не имеет особого смысла
Извините, немедленно удалю все тесты.
Они тестируется в режиме Test-driven development. И оставлять рудименты в виде юнит-тестов после этого не нужно. И некоторые ваши функции без аргументов. Т.е. к ним неприменимо юнит-тестирование, как тут его описывают. Что же за тестирование у вас в таком случае?
Так у вас какой-то свой, новаторский Test Driven Development, с удалением тестов после того как они становятся не нужны? И с обязательным наличием аргументов у всех функций тестируемого кода? Гениально! Нужно немедленно связаться с Кентом Беком и Джеймсом Греннингом, они оказывается все эти годы делали какую-то фигню. Невероятно!
А если серьёзно — вы, пожалуйста, почитайте книжек умных прежде чем утверждениями бросаться. Я понимаю что ваши вопросы появились из-за того что статью вы не поняли, но обычно тон комментариев в таких случаях вопросительный, а не поучающий всех подряд что и как правильно.
Мне вот как и автору не понятно чего конкретно вы хотите. Пока, честно, кажется что просто показать что вы здесь самый умный и термины у вас самые правильные. Но предположу что это не так и попробую объяснить что знаю.
не понял что конкретно тестировалось
Модульное тестирование рассматривает тестирование модулей программы по отдельности. Тест представляет из себя функцию, которая вызывает функции тестируемого модуля и проверяет его реакцию — возвращаемые значения; вызов функций других модулей, от которых зависит тестируемый; если поддерживается языком — исключения; etc. Тестов как правило много — код тестов легко может быть объёмнее кода самого модуля. Тесты используются на этапе подготовки кода, в результирующей программе их нет.
пример десятка функций подвергавшихся тестированию и что они должны были делать
Animation_AntiPoisoning_Enter(animationParameters) — активирует анимацию перебора разрядов для предотвращения отравления катодов
Animation_AntiPoisoning_Periodic(time) — выводит следующий кадр анимации перебора разрядов
Animation_EditHours_Enter(animationParameters) — активирует анимацию редактирования часов
Помогло?
Не ясна совокупная выгода такого подхода и контекст.
Выгода заключается по меньшей мере в уменьшении количества неотловленных ошибок, облегчении редактирования кода (тесты покажут что после изменений не сломалось по крайней мере то что они тестируют), улучшении качества кода (более мелкие модули с меньшей связанностью, большее соответствие принципам SOLID). В численном виде выразить сложно, но попытки были — если есть много свободного времени то можно поискать и поизучать research papers по этой теме в интернете. Контекст — написание программ.
это же не тестирование, а моделирование
Нет, это не моделирование. Моделирование подразумевает описание реакции модели на все возможные ситуации в которых она может оказаться. При модульном тестировании в пределах каждого теста описывается один-единственный сценарий взаимодействия. «Если светофор переключился на красный свет, то автопилот должен затормозить»; «если светофор переключился на зелёный свет и дорога свободна, то автопилот должен начать движение» — для проверки этих утверждений вам не нужно моделировать весь светофор и окружающую его улицу.
моделирование датчиков без их наличия настолько рисковано, что не вижу смысла этим заниматься
Не моделирование датчиков, а тестирование кода который будет с ними работать. Идея в том что значительная часть информации доступна заранее, а расхождения можно будет скорректировать когда о них станет известно. Как говорят Томас и Хант в «Прагматичном рпограммисте» — качественный код это такой код, который легко поддаётся изменению.
Отличная статья, благодарю. Я правильно понимаю что Вы были первым на своём месте работы, кто начал применять юнит-тесты и убедил в их пользе коллег? Расскажите, пожалуйста, как Вам удалось последнее.
Возможно я невнимательно читал, но я так и не понял в чём по мнению автора различия между инъекцией и инверсией. Я не имею ввиду что их нет, просто вот именно по статье я нифига не понял. Сначала просто пару-тройку раз говорится что это не одно и то-же, а потом идёт длинное описание инверсии.
Антенну беспроводного модуля закрепил на столе, стоящем в углу зала. Высота — на уровне пояса. Разницы по качеству между проводом и беспроводным адаптером не видно. Связь надежная по всему залу (4х4 метра минус стол в углу и диван у стены). Артефактов и отключений во время использования не замечено (только при старте SteamVR могут быть приколы, но это не в технологии дело, просто SteamVR сырой).
К слову у друга Vive Pro с беспроводом и отличий/проблем на глаз так-же не видно, но у него игровая область поменьше — в основном на месте стоит. Так что возможно Вам стоит поиграться с расположением антенны и проблем станет меньше.
Думаю стоит упомянуть что беспроводной модуль сам по себе жрёт много процессора — без него у меня всё (что щупал) отлично работало на Core i5 4570. С ним у меня даже SteamVR Home начал кашлять — подёргивания картинки, видимые «квадраты» от понижения качества изображения. Переход на свежую ряженку решил проблему.
Как-то сумбурно. Так затрачено было 2 миллиона и деньги быстро закончились, или всего затрат вышло на 100 тысяч? Проектом занимался инженер и его помощник, или один инженер? Или это две отдельные итерации с двумя разными исполнителями? Написано что весь НИОКР обошёлся в 3 месяца работы инженера и 100тр — инженер получал зарплату отдельно от этих 100тр? Если нет то, надеюсь, хотя-бы обошлось без приковывания инженера наручниками к батарее?
Во-первых спасибо за Вашу статью и исходники. Во-вторых это вопрос скорее уважения к собственному труду и чужому времени — раз уж основная часть работы сделана, то и мелкие косяки можно бы и подправить.
Можно и так сделать, только вот зачем? Обменивать хоть сколько-нибудь значительное время своей жизни на выгоду в ошеломительных рублей 50 не очень-то разумно.
Правда о том, что ты докопался до забора, автор той статьи тебя не понял и ты теперь ходишь и рассказываешь даже в соседних темах какой он неразумный? На твой вопрос, к слову, дальше дали ответ, а встречный вопрос ты проигнорировал. Ту статью я считаю достаточно качественной, а твоё поведение (и ещё пары товарищей из комментов) — неадекватным и деструктивным.
Рискну предположить что, во-первых, автор неправильно понял вопрос, а во вторых что, упрощенно говоря, класс критической секции в конструкторе (при создании объекта) выключает прерывания, а в деструкторе (при выходе объекта из области видимости) включает. Если так, то что именно будет не работать в многопоточной системе?
TDD предназначен в первую очередь для разработки той части программы, которая от платформы не зависит (а выделить эту часть из программы — достаточно сложный навык, которому надо учиться) — то есть к пересылке данных через DMA он отношения вообще не имеет. Вы-же фактически утверждаете что пинцетом неудобно гвозди забивать, а значит пинцеты бесполезные.
Но насчёт отставания вы правы, по крайней мере в культуре разработки софта разница очень заметна. Из моего опыта редкий программист встраиваемых систем пользуется системами контроля версий, например. А за всякие SOLID, паттерны и интерфейсы вообще можно хипстером-выпендрёжником прослыть. Хотя конечно может это мне просто не везёт так.
Ага, особенно Греннинг.
Послушайте, я уже понял что ваше мнение относительно юнит-тестирования (и полагаю не только его) заключается в том что вы умнее всех. На фоне этого любые попытки объяснить вам тему разбиваются о ваш огромный опыт. Вы не задаёте вопросы, вы требуете объяснений «почему вы делаете так глупо, правильно же вот так». Когда вам указывают на некорректность или бессмысленность вопроса — вы реагируете в стиле «не отвечаешь — значит не можешь, шах и мат».
Искренне надеюсь что нам никогда не придётся работать вместе. Всего доброго.
Ох как неловко вышло… Надо пойти всем рассказать, а то тысячи и миллионы глупцов называют юнит-моделирование юнит-тестированием и даже не догадываются! Спасибо за вашу мудрость.
Вы этот вывод сделали из того что кода больше писать? Ну да, действительно. Вот бы у меня тоже сложность программирования зависела только от скорости печати. Восхищён вами.
Извините, немедленно удалю все тесты.
Так у вас какой-то свой, новаторский Test Driven Development, с удалением тестов после того как они становятся не нужны? И с обязательным наличием аргументов у всех функций тестируемого кода? Гениально! Нужно немедленно связаться с Кентом Беком и Джеймсом Греннингом, они оказывается все эти годы делали какую-то фигню. Невероятно!
А если серьёзно — вы, пожалуйста, почитайте книжек умных прежде чем утверждениями бросаться. Я понимаю что ваши вопросы появились из-за того что статью вы не поняли, но обычно тон комментариев в таких случаях вопросительный, а не поучающий всех подряд что и как правильно.
Модульное тестирование рассматривает тестирование модулей программы по отдельности. Тест представляет из себя функцию, которая вызывает функции тестируемого модуля и проверяет его реакцию — возвращаемые значения; вызов функций других модулей, от которых зависит тестируемый; если поддерживается языком — исключения; etc. Тестов как правило много — код тестов легко может быть объёмнее кода самого модуля. Тесты используются на этапе подготовки кода, в результирующей программе их нет.
Хорошо, вот из моего текущего домашнего проекта:
Помогло?
Выгода заключается по меньшей мере в уменьшении количества неотловленных ошибок, облегчении редактирования кода (тесты покажут что после изменений не сломалось по крайней мере то что они тестируют), улучшении качества кода (более мелкие модули с меньшей связанностью, большее соответствие принципам SOLID). В численном виде выразить сложно, но попытки были — если есть много свободного времени то можно поискать и поизучать research papers по этой теме в интернете. Контекст — написание программ.
Нет, это не моделирование. Моделирование подразумевает описание реакции модели на все возможные ситуации в которых она может оказаться. При модульном тестировании в пределах каждого теста описывается один-единственный сценарий взаимодействия. «Если светофор переключился на красный свет, то автопилот должен затормозить»; «если светофор переключился на зелёный свет и дорога свободна, то автопилот должен начать движение» — для проверки этих утверждений вам не нужно моделировать весь светофор и окружающую его улицу.
Не моделирование датчиков, а тестирование кода который будет с ними работать. Идея в том что значительная часть информации доступна заранее, а расхождения можно будет скорректировать когда о них станет известно. Как говорят Томас и Хант в «Прагматичном рпограммисте» — качественный код это такой код, который легко поддаётся изменению.
Антенну беспроводного модуля закрепил на столе, стоящем в углу зала. Высота — на уровне пояса. Разницы по качеству между проводом и беспроводным адаптером не видно. Связь надежная по всему залу (4х4 метра минус стол в углу и диван у стены). Артефактов и отключений во время использования не замечено (только при старте SteamVR могут быть приколы, но это не в технологии дело, просто SteamVR сырой).
К слову у друга Vive Pro с беспроводом и отличий/проблем на глаз так-же не видно, но у него игровая область поменьше — в основном на месте стоит. Так что возможно Вам стоит поиграться с расположением антенны и проблем станет меньше.
Думаю стоит упомянуть что беспроводной модуль сам по себе жрёт много процессора — без него у меня всё (что щупал) отлично работало на Core i5 4570. С ним у меня даже SteamVR Home начал кашлять — подёргивания картинки, видимые «квадраты» от понижения качества изображения. Переход на свежую ряженку решил проблему.
www.reddit.com/r/embedded/comments/gg5704/i_published_the_code_for_quake_for_stm32_port
TDD предназначен в первую очередь для разработки той части программы, которая от платформы не зависит (а выделить эту часть из программы — достаточно сложный навык, которому надо учиться) — то есть к пересылке данных через DMA он отношения вообще не имеет. Вы-же фактически утверждаете что пинцетом неудобно гвозди забивать, а значит пинцеты бесполезные.