fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

8.8K
active users

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

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

habr.com/ru/articles/925446/

ХабрTDD: разработка быстрее и качественнееThis article in English Все мы стремимся создавать более качественное программное обеспечение и делать это быстрее. Я считаю, что разработка через тестирование предлагает нам путь к этой цели....

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

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

habr.com/ru/articles/925162/

ХабрСкриншот-тестирование фронтенда: руководство по применению в 2025 годуВ мире тестирования фронтенд-приложений существует одна забавная особенность. Визуальное представление нашей программы почти всегда остается вне зоны покрытия тестами,  даже несмотря на то,...

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

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

habr.com/ru/companies/otus/art

ХабрTest Driven Development: сначала тесты, потом реализацияTest Driven Development в простом понимании означает написание тестов перед написанием кода, но каждый, кто практиковал его по‑настоящему, знает, что это понятие гораздо шире. Наличие...

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

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

habr.com/ru/companies/ruvds/ar

ХабрГрязный кодЭдсгер Дейкстра: «Грязно и быстро — мне это не понравится» «Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к...

TDD: да или нет?

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

habr.com/ru/articles/839658/

ХабрTDD: да или нет?Для тех, кто не знаком, с методологией TDD, советую предварительно ознакомится с материалами: отличная статья про суть подхода , моя статья с небольшим практическим примером Эта статья, в формате...