Привет, Хабр! Меня зовут Владимир, я работаю программистом в компании Quadcode. Вот уже почти полтора десятилетия я при помощи доброго десятка языков программирования разрабатываю приложения - от простых, вроде маленького плагина для Emacs, до сложных распределенных систем. Последние 4 года своей жизни я посвятил компании Quadcode, где занимаюсь разработкой транспортной подсистемы. Лет пять назад я вплотную столкнулся с адептами TDD (test-driven development) и это произвело на меня настолько сильное впечатление и оставило так много эмоций, что я написал “для своих” критический разбор наиболее часто встречаемых мною тезисов об этой технике (я бы даже сказал - учении). До сих пор мое мнение о TDD не изменилось, так что хотел бы описать его под катом и предлагаю обсудить вместе спорные моменты в комментариях.
TDD *
Разработка через тестирование
Реализация алгоритма Минимакс на примере игры «Крестики-Нолики»
Для того чтобы сделать игру непобедимой, было необходимо создать алгоритм, который может рассчитать все возможные ходы для «компьютерного» игрока. Далее, нужно использовать некоторую метрику, чтобы определить, какой ход является предпочтительным. После долгих исследований стало понятно, что алгоритм Минимакс, был тем, что мне нужно.
Понимание основ алгоритма и реализация игры заняли некоторое время. Я нашел много примеров кода и объяснений, тем не менее это оказалось не такой уж простой затеей. Надеюсь этот пост поможет некоторым из читателей оценить элегантность этого алгоритма.
Может ли автоматизированное тестирование заменить ручное?
Этот, казалось бы, глупый вопрос задают с завидной регулярностью. Казалось бы уже давно все должно быть понятно, но нет.
Disclaimer: данная статья написана с учетом опыта разработки в определенной (хоть и самой массовой) сфере ПО, а именно e-commerce. В других сферах правила игры могут разительно отличаться.
Я работал в тестировании 3 года, в автоматизации 7 лет, и в разработке - все оставшееся время, и вскоре я буду выступать на Национальной Конференции по Тестированию в Великобритании с ответом на этот вопрос. Но конференция еще не скоро, а многим, видно, интересно узнать ответ уже сейчас.
Retrofit: удобные разработка и тестирование API
Если вы занимались крупными Java-проектами, то вы, наверное, помните старый добрый WSDL (Web Services Description Language, язык описания веб-сервисов), за которым стоят IBM и Microsoft. WSDL — это язык описания веб-сервисов, основанный на XML. А, может, вы всё ещё пользуетесь этим языком? WSDL и его брат-близнец — язык XML Schema, относятся к тем стандартам W3C, которые являются излюбленным объектом ненависти бывалых программистов. Файлы спецификаций WSDL не особенно легко читать людям, а об удобстве их ручного составления лучше и не говорить. Но, к счастью, работать с подобными файлами вручную и не нужно. Они могут быть сгенерированы конечной точкой сервера и переданы прямо в кодогенератор для создания объектов переноса данных (DTO, Data Transfer Object) и стабов сервиса.
Истории
Почему большинство юнит тестов — пустая трата времени? (перевод статьи)
Перевод статьи "Why most unit testing is waste?"
Автор: James O Coplien, Перевод: Епишев Александр
1.1 Наши дни
Во времена FORTRAN, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
Пишем unit тесты так, чтобы не было мучительно больно
Любую задачу в программировании можно выполнить массой разных способов, и не все они одинаково полезны. Хочу рассказать о том, как можно накосячить при написании модульных тестов. Я пишу мобильные приложения уже 6 лет, и в моем «багаже» много разных кейсов. Уверен, что кому-то будет полезно.
Кому с Redux жить хорошо
Существует мнение, что разработка через тестирование, или по канонам Test Driven Development (TDD) для фронтенда не применима. В данной статье я постараюсь развенчать этот миф и покажу, что это не только возможно, но и очень удобно и приятно.
Сам по себе React достаточно понятен любому разработчику, чего не скажешь про Redux. На первый взгляд может показаться, что это какой-то монструозный и непонятный инструмент. Прочитав данную статью, вы узнаете как разрабатывать приложения через тестирование на React, используя Redux, поймёте преимущества его использования, научитесь не открывать браузер при разработке фронтенд-приложений и экономить время на дебаге. Возможно, найдёте что-то новое для себя про написание фронтовых тестов.
Как я пытался улучшить Laravel, а сделал только хуже
Laravel – классный PHP-фреймворк, мы им постоянно пользуемся в компании. Но как известно, ничто в мире не идеально, можно всегда предложить улучшения.
Несколько недель назад я попытался сделать одно маленькие улучшение по части тестов в Laravel, открыл два пулл-реквеста (#1 и #2). Оба пулл-реквеста были отклонены автором фреймворка Тейлором, но в итоге он сам в этот же день опубликовал собственную реализацию того же функционала, о чём даже в твиттере похвалился. И, о боги, реализацию ужасную!
Вам не нужны юнит-тесты
Да, вы не ослышались – именно так! В IT-сообществе прочно укоренилось мнение, что все эти тесты вам хоть как-то помогают, но так ли это на самом деле? Вы сами пробовали мыслить критически и анализировать это расхожее мнение? Хипстеры придумывают кучу парадигм – TDD, BDD, ПДД, ГИБДД – лишь чтобы создать иллюзию бурной деятельности и хоть как-то оправдать свою зарплату. Но задумайтесь, что будет, если вы (либо ваши программисты) начнете все свое время уделять исключительно написанию кода? Для тестирования есть отдельное направление и целые подразделения. Вы же не заставляете программистов писать требования, так? Тогда почему они должны писать тесты? Всех согласных и несогласных прошу проследовать внутрь поста, где я вам наглядно покажу, что юнит (и интеграционные) тесты – великое зло!
Двигайся быстрее и ломай преграды? Не так быстро, когда дело касается встраиваемых систем
Шон Престридж – старший инженер по применению (FAE), руководитель группы FAE американского подразделения IAR Systems – в статье «Move fast and break things? Not so fast in embedded», рассказывает о специфике разработки программного обеспечения для встраиваемых систем, уделяя особое внимание вопросам качества кода и тестирования.
«Двигайся быстрее и ломай преграды» — это подход, озвученный Марком Цукербергом, который он внедряет в культуру разработки Facebook. Несмотря на то, что он чудесно звучит, когда мы говорим о быстром создании и запуске новых функций (даже если они не идеальны), все же он теряет свою красоту, если попытаться применить его к разработке программного обеспечения для встраиваемых систем.
За счет чего TDD “драйвит” разработку
Статей о TDD достаточно много, и я обратил внимание на то, что все они затрагивают преимущественно техническую составляющую этого подхода, и практически никак не описывают ментальные принципы, лежащие в основе TDD.
Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.
В статье речь пойдет о неких абстракциях, которые применимы на разных слоях мировоззрения и, вне зависимости от контекста, помогают достигать хорошего результата. Универсальность этих абстракций и факт, что они применимы даже к процессу написания кода, сделали меня ярым приверженцем как TDD подхода, так и этих абстракций.
REACT + JEST = TDD ❤️
Как и моим коллегам, мне нравится пробовать новые подходы, методологии и практики, заниматься повышением качества и скорости разработки. В начале этого года мы с командой решили попробовать одну из техник экстремального программирования — TDD.
От том, что из этого вышло, и будет моя статья, добро пожаловать под кат!
Что необходимо учитывать при юнит-тестировании фронтенда
Обращаем ваше внимание еще на одну новинку, доступную у нас в предзаказе — книгу о юнит-тестировании.
Автор сегодняшней публикации кратко и доступно рассказывает о достоинствах unit testing и TDD на примере фронтенда.
Приятного чтения!
Ближайшие события
С чего начинаются тесты
Тестов много не бывает. И речь идёт не только о наращивании их количества (что само по себе, конечно, тоже хорошо) — речь идёт о разнообразии самих видов тестов. Даже не напрягая воображение можно вспомнить несколько способов протестировать ваше приложение: Unit-тесты, интеграционные тесты, API-тесты, системные тесты… и это не вспоминая о том, что тесты ещё бывают функциональными, нагрузочными, направленными на отказоустойчивость...
Но с чего же начинать писать тесты для новых проектов? Лично для меня, как для программиста, самый интуитивный ответ — это Unit-тесты. Однако опрометчиво накидываться на сочинение Unit-тестов может не только оказаться бесполезым занятием, но даже нанести вред в будущей разработке проекта.
Поэтому в этой статье я хочу предложить вам альтернативу и расскажу о том, почему лучше всего в самую первую очередь писать самые сложные тесты (системные), а затем уже — все остальные.
Практики автоматического тестирования Retail Rocket
Я часто собеседую кандидатов на позиции .Net разработчиков в Retail Rocket. В прошлом работал в компаниях с различными командами. И далеко не один раз встречал и продолжаю встречать мнение, что “автотесты хорошо, но на них нет времени, писать их дорого, тестировать должны тестировщики”. Такое мнение не у всех, но встречается нередко (не исключаю, что мне так «везет»). В связи с этим хочу поделиться нашим подходом к автоматическому тестированию и обеспечению качества. Расскажу путь, который мы в Retail Rocket прошли за последние 3-4 года, к чему пришли сейчас, и — главное — что дают нам автотесты и для чего мы их пишем. Надеюсь, статья кого-нибудь сподвигнет писать автотесты, кого-то — писать больше автотестов, а кому-то, возможно, поможет избежать ошибок, с которыми мы сталкивались.
Язык тестовых сценариев Testo Lang: простая автоматизация сложных тестов
Если Вы разрабатываете более-менее сложный программный продукт, то Вам должна быть знакома ситуация, когда системные (end-to-end) тесты по тем или иным причинам автоматизировать не удаётся. На это могут быть разные причины, я приведу несколько примеров:
- У приложения нет и не может быть API, за которое можно зацепиться, по соображениям безопасности;
- Приходится поддерживать legacy-проект, про автоматизацию тестирования которого никто никогда не задумывался;
- Во время тестирования задействуется сторонний продукт, например — антивирус;
- Необходимо проверить работоспособность продукта на большом количестве различных целевых платформ;
- Тестовый стенд представляет собой сложную гетерогенную систему, включающую в себя промежуточное сетевое оборудование.
Эти и многие другие ситуации приводят к худшему кошмару любого разработчика — ручному тестированию. Самое неприятное заключается в том, что нельзя провести тестирование один раз и забыть о нём. Нет, нам приходится перед каждым релизом (а может и чаще) раскатывать виртуалки, устанавливать туда тестируемое приложение и тыкать по кнопкам снова и снова, чтобы убедиться, что мы не словили регрессию.
Если Вы ищете решение этой проблемы — то прошу под кат.
Деконструкция TDD
Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём разные темы из компьютерной науки и деконструируем их по полочкам. Начнём мы с разработки через тестирование.
Test Driven Development
Суть этого подхода заключается в ритуализации процесса разработки. То есть в некритическом безусловном выполнении определённых простых действий.
Этот ритуал сделает ваш код красивым и надёжным. Поддерживать его будет легко и просто. А разработка будет простой и быстрой. Так во всяком случае настоятельно убеждают нас проповедники TDD.
Изучаю Scala: Часть 3 — Юнит Тесты
Привет, Хабр! Мало написать хороший код. Нужно еще покрыть его хорошими Юнит Тестами. В прошлой статье я сделал простой веб сервер. Теперь попробую написать насколько тестов. Обычных, Property-based и с моками. За подробностями добро пожаловать под кат.
Юнит-тесты в uVision Keil (и не только)
Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?
Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".
Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.
Как должны выглядеть модели?
Наверняка все слышали что про модели, MVC, AR и другие замечательные слова.
Но все ли до конца понимают, что эти слова означают?
Все ли понимают что такое модель и как она должна выглядеть
Давайте порассуждаем (и не только) на эту тему.
Вклад авторов
asolntsev 303.2tangro 148.0sody 96.0BurundukXP 77.4AlexanderByndyu 69.0Unrul 59.0Tiendil 56.0Igmat 53.0headfire 53.0ETman 52.0