Как разрабатывать утилиты для тестов embedded-прошивок без железа: практика Test Driven Development

Часто SDET-инженеры, работающие со встраиваемыми системами, не приступают к работе, пока не получат реальное железо: датчик, микроконтроллер или плату с новым чипом. Такой подход обычно оправдывают тем, что без физического девайса «на столе» писать корректно работающий софт невозможно. Очевидный минус: увеличивается время выхода продукта и нового функционала на рынок. Но разработку можно начать, даже не имея в своем распоряжении устройства: все дело в договоренности между командами. Меня зовут Рустам Ахмадуллин, я старший инженер по системной верификации аппаратуры в YADRO. Расскажу на примере датчика температуры LM75A, как написать API без физического доступа к устройству и его прошивке. Разберем методологию Test Driven Development, при которой разработка начинается с написания автоматизированных тестов, а не самого кода.

https://habr.com/ru/companies/yadro/articles/1001256/

#tdd #pytest #embedded #i2c #test_driven_development #sdet #uv #system_software_development #python #aqa

I have updated CUTest, my tool for unit tests and test driven development in C programming, to add an "early quit" option (stops on the first failed test).

#programming #c_programming #test_driven_development

https://baillehachepascal.dev/2022/cutest.php

TDD: разработка быстрее и качественнее

Все мы стремимся создавать более качественное программное обеспечение и делать это быстрее. Я считаю, что разработка через тестирование предлагает нам путь к этой цели. Все еще боитесь использовать этот подход? Тогда я приглашаю вас обсудить советы и приемы помогающие раскрыть преимущества TDD!

https://habr.com/ru/articles/925446/

#tdd #test_driven_development #software_development #testing #agile #unit_testing #code_quality #refactoring #test_first

Скриншот-тестирование фронтенда: руководство по применению в 2025 году

В мире тестирования фронтенд-приложений существует одна забавная особенность. Визуальное представление нашей программы почти всегда остается вне зоны покрытия тестами, даже несмотря на то, что фронтенд-разработка это в первую очередь про визуал. Если посмотреть на то как пишут тесты на типичном проекте, то в основном это будут юнит-тесты проверяющие внутреннюю специфику компонентов или отдельных функций плюс какие-нибудь е2е-тесты проверяющие отдельные сценарии. Чаще всего все эти тесты полностью игнорируют визуальную составляющую, и в случаях если у вас слетели шрифты, отступы, или просто html-элемент скрыт стилями, то тесты все-равно будут зелеными. Часто приходилось видеть тесты опосредовано проверяющие визуальное отображение html-элемента, что-то в стиле expect(elem.classList.contains("visible")).toBe(true) . Говорить о надежности таких тестов конечно-же не приходится, так как изменив содержимое css-селектора стилизующий данный класс, данный тест все еще будет зелёным, несмотря на то что по факту элемент будет скрыт. Результат от подобных тестов вполне ожидаемый. Обновили версию UI-библиотеки и на всем проекте поехала верстка? Тесты зелёные. Случайно переопределили CSS-переменную и теперь вместо приятной тщательно подобранной дизайнером гаммы цветов вы видите лишь кислотно-вырвиглазную солянку? “Бывает, надо было ручками протестировать” - скажет менеджер. Решить данную проблему нам поможет добавление скриншот-тестирования на проект. Используя данный вид тестирования вкупе с классическими юнит- и е2е-тестами мы практически полностью избавляемся от необходимости ручного тестирования наших фронтенд-приложений.

https://habr.com/ru/articles/925162/

#screenshotbased_метод_тестирования #test_driven_development #testng #puppeteer #jest

Test Driven Development: сначала тесты, потом реализация

Для большинства разработчиков очевидно, что сначала должен появляться код, а только потом тесты для проверки работоспособности этого кода. Но в этой статье мы рассмотрим обратный процесс — Test Driven Development. В простом понимании это означает написание тестов перед написанием кода, но на самом деле этот подход гораздо шире. Тесты перед реализацией заставляют вас больше думать о том, что на самом деле ожидается, а «как» приходит позже, и «как» — это деталь реализации, которую можно изменить с помощью рефакторинга. В этой статье, написанной на основе публикации Rogério Chaves «The complete guide for TDD with LLMs» мы рассмотрим использование больших языковых моделей (LLM) для Test Driven Development.

https://habr.com/ru/companies/otus/articles/910488/

#llmмодели #tdd #pytest #Тестирование_с_LLM #Test_Driven_Development

anyone interested in helping out with maintaining the message parser for #deltachat desktop?

It's #test_driven_development like a #coding_puzzle, written in #rust  with the #nom parser combinator library.

Repo: https://github.com/deltachat/message-parser

We have some bugs that I currently don't have the capacity to fix.

[Перевод] Грязный код

Эдсгер Дейкстра: «Грязно и быстро — мне это не понравится» «Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к лучшему». Clean Code В этом эссе я хочу рассказать о том, как пишу код. Я буду называть свою методику «грязным кодом», потому что часто нарушаю рекомендации «чистого кода» — популярной концепции написания кода. Вообще, я на самом деле не считаю свой код абсолютно грязным: местами он немного уродлив, но по большей части я им доволен, и он достаточно прост в поддержке, обеспечивая при этом разумные уровни качества. Кроме того, я не пытаюсь своим эссе убедить вас писать грязный код. Скорее, я хочу показать, что таким способом можно писать достаточно успешное ПО, и, надеюсь обеспечить некий баланс в обсуждениях методологий разработки ПО. Я программирую уже довольно давно и видел разнообразные подходы к обеспечению работоспособности ПО. Кто-то любит объектно-ориентированное программирование (я тоже), другие умные люди его ненавидят. Кому-то нравится выразительность динамических языков, кого-то она бесит. Кто-то успешно выпускает программы, строго следуя концепции Test Driven Development, другие добавляют в конце проекта несколько сквозных тестов, а многие остаются где-то посередине этих крайних точек. Я был свидетелем проектов, выпускавших и поддерживавших успешное ПО на основе всех этих разнообразных подходов. Поэтому повторюсь, что моя цель не убедить вас, что мой способ кодинга единственно возможный, а показать вам (и в особенности начинающим разработчикам, которых легко запугать терминами наподобие «чистого кода»), что можно иметь успешную карьеру программиста, пользуясь множеством различных подходов, и что мой — один из них.

https://habr.com/ru/companies/ruvds/articles/865026/

#htmx #чистый_код #принцип_единой_ответственности #test_driven_development #юниттесты #интеграционные_тесты #ruvds_переводы

TDD: да или нет?

Эта статья, в формате небольших тезисов, нацелена на открытие дискуссии на тему "Test Driven Development" – методологии разработки через тестирование. На моем текущем месте работы существует несколько мнений: начиная от полного принятия и стремления(к tdd), как к идеальному инструменту написания рабочего и лаконичного кода, вплоть до полного отвержения: TDD не работает, убивает время разработчиков, увеличивая при этом time-to-market. К каждому тезису, которые я выделил, я буду оставлять свой комментарий, стараясь быть объективным и не транслировать какую-либо позицию. Итак, поехали

https://habr.com/ru/articles/839658/

#tdd #test_driven_development #tests #time_to_market