TDD *

В первой части был написан лексер. Далее будет рассмотрена разработка парсера.

Парсер

Парсер будет реализован по алгоритму сортировочной станции, так как он достаточно прост и не нуждается в рекурсии. Сам алгоритм таков:

В начале даются пустой выходной поток и пустой стек. Начнём читать токены из входного потока по очереди.

• Если это число, то передать его в выходной поток.
• Если это лево ассоциативный оператор, то выталкиваем токены из стека в выходной поток до тех пор, пока он не опустеет, либо не его вершине не встретится скобка, или оператор с более низким приоритетом.
• Если это открывающая скобка, то положить её в стек.
• Если это закрывающая скобка, то выталкиваем токены из стека в выходной поток до обнаружения открывающей скобки. Вытолкнуть открывающую скобку из стека, но не передавать её в выходной поток. Если стек опустел, и скобка не найдена, то генерируем ошибку.

После достижения конца входного потока, вытолкнуть все оставшиеся в стеке операторы в выходной поток. Если в нём найдено что-либо кроме операторов, то генерируем ошибку.

Прикинем, какие тесты могут понадобиться для начала.

• При получении пустого списка, возвращается пустой список.
• При получении списка с одним числом, возвращается список с этим числом.
• При получении [1 + 2], возвращается [1 2 +].
• При получении [1 + 2 + 3], возвращается [1 2 + 3 +], так как оператор + является лево ассоциативным.
• При получении [1 * 2 + 3], возвращается [1 2 * 3 +].
• При получении [1 + 2 * 3], возвращается [1 2 3 * +], так как оператор * имеет больший приоритет.

Со скобками и ошибками разберёмся позднее. Итак, напишем первый тест из списка.

TEST_CLASS(ParserTests) {
public:
    TEST_METHOD(Should_return_empty_list_when_put_empty_list) {
        Tokens tokens = Parser::Parse({});
        Assert::IsTrue(tokens.empty());
    }
};

Введение

Многие C++ программисты слышали про разработку через тестирование. Но почти все материалы по данной теме касаются более высокоуровневых языков и сосредоточены больше на общей теории, чем на практике. Итак, в данной статье я попробую привести пример пошаговой разработки через тестирование небольшого проекта на C++. А именно, как можно предположить из названия, простого интерпретатора математических выражений. Такой проект также является неплохой code kata, так как на его выполнение затрачивается не более часа (если не писать параллельно статью об этом).

Архитектура

Несмотря на то, что при использовании TDD архитектура приложения постепенно проявляется сама собой, начальная её проработка всё же необходима. Благодаря этому может значительно снизиться общее время, затраченное на реализацию. Это особенно эффективно в тех случаях, когда существуют готовые примеры подобных систем, которые можно взять за образец. В данном случае, существует вполне устоявшееся мнение о том, как должны быть устроены компиляторы и интерпретаторы, чем и можно воспользоваться.

Существует множество библиотек и инструментов, которые могут облегчить разработку интерпретаторов и компиляторов. Начиная от Boost.Spirit и заканчивая ANTLR и Bison. Можно даже запустить канал интерпретатора командной строки через popen и вычислить выражение через него. Целью данной статье является пошаговая разработка достаточно сложной системы с помощью TDD, поэтому будет использоваться только стандартная библиотека C++ и встроенный в IDE тестовый фреймворк.

От переводчика. Давид Хейнемейер Ханссон данной статьей поднял острую тему обязательности использования TDD и, даже, возможного вреда от написания тестов перед написанием кода. Именно эта статья послужила лейтмотивом уже пяти встреч на тему жив ли TDD, на которых Давид, Кент Бек и Мартин Фаулер обсуждают достоинства и недостатки TDD, рамки применимости и ограничения. Для тех у кого восприятие устного английского оставляет желать лучшего, SergeyT публикует краткие саммари в своем G+.

Примечание от переводчика: мой опыт знакомства с разработкой через тестирование во многом схож с тем, что описывает автор (хотя и начался на несколько лет позже). Я начинал изучать TDD самостоятельно, на работе, исправляя баги и создавая новые модули с нуля. Эффект от применения TDD произвёл на меня настолько мощное впечатление, что породил желание делиться умением применять эту технику с другими. Я также проводил Code Retreat-ы внутри и вне своей компании. И я вижу те же проблемы в своих тренингах — очень сложно взять и «впихнуть» понимание сути TDD в чужие головы.

Поэтому в данной статье я вижу свежий взгляд на проблему, который, возможно, даст новый толчок в изучении TDD мне и моим коллегам. Думаю, она пригодится и прочим интересующимся разработкой через тестирование. Буду рад увидеть Ваши комментарии.

Я использую TDD как инструмент для изучения и преподавания основ модульного дизайна, но должен заметить, что эффективность обучения сильно зависит от дисциплины студентов. Я хочу делать своё дело всё лучше и лучше, и поэтому постоянно ищу новые способы планировать критические шаги¹ в преподавании TDD. Думаю, я нашёл микротехнику, которая помогает в этом деле, и хочу немедленно поделиться ей с вами.

TL;DR?

Многие сторонники TDD рекомендуют подход под названием «интенсивная практика», но я догадываюсь, что у Вас не будет возможности тратить много рабочего времени на практику. Я советую людям «применять TDD осознанно», но до сих пор не знал хорошего способа достаточно доступно объяснить смысл этих слов, что снижало ценность моего совета. Вы можете начать применять оба подхода (интенсивный и осознанный) одновременно, если начнёте исправлять баги через тесты. Даже если Вы до сих пор не умеете проектировать софт на экспертном уровне, то, по крайней мере, Вы уже можете учиться как эксперт. И исправление багов через тесты даст Вам естественную и не слишком рискованную возможность делать это. У Вас будет возможность практиковаться в TDD усердно и осознанно. Если у Вас есть возможность исправлять баги на работе в одиночку, то Вы можете использовать эти практики, не привлекая лишнего внимания, которое обычно возникает при разговорах об «интенсивной практике». Просто говорите всем, что Вы исправляете баги. Это всем понравится.

Вам всего лишь надо начать с написания теста, который будет падать до тех пор, пока Вы не исправите баг. Если Вам нужно больше подробностей, прежде чем начать, продолжайте чтение.

Вступление

Вы всё ещё тестируете с помощью JUnit и не обращаете внимания на TestNG? Тогда мы идём к вам.

Одним из преимуществ TestNG является возможность создания тестовых массивов данных для одного или нескольких тестов. Но мало кто использует такое преимущество от @DataProvider как пустой набор тестовых данных. В чём оно выражается?

Допустим у нас есть некий тест testData(String value) и метод datas обеспечивающий DataProvider. Если datas вернёт нам массив из 3-х элементов, то testData выполнится 3 раза. Но если datas вернёт нам пустой массив, то testData не выполнится ни разу
Давайте попробуем воспользоваться данной особенностью.

В наших с вами интернетах недавно поднялся нешуточный шум по поводу того, жив ли TDD сейчас, нужен ли он, и в каком виде. Все началось со статьи Дэвида Хансона «TDD is dead. Long living testing», после которой последовали статьи многих авторов и живые обсуждения этой проблемы включая hangout вместе с Дэвидом, Кентом Беком и Мартином Фаулером (кстати, очередной hangout будет завтра, 16 мая).

Но немногие знают, что за несколько дней до этого все тот же Мартин Фаулер постарался дать определение модульного теста (bliki:UnitTest), перевод которого представлен ниже. А после перевода идут кое-какие мои мысли по этому поводу.

Начну с коротенькой предыстории. Была у меня задача написать резерватор для номеров в отеле, я полез на всеми нами любимый packagist, в поисках готового решения и, к моему глубокому разочарованию, не нашел ничего. Ну, надо сделать — сделаем. Код написан, покрыт функциональными тестами в приложении. Через пару недель я решил выложить написанный бандл на github. Но передо мной встал вопрос: при тестировании отдельного бандла у нас нет самого приложения. Начал гуглить, и опять не нашел ничего стоящего. В общем пришлось собирать информацию по крупицам, и сейчас я хочу поделиться своим опытом с вами.

Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.

Их книги произвели на меня впечатление и воодушивили попробовать некоторые описанные практики. Refactoring, TDD, XP, и, наконец, Continuous Integration, это то, что в последнее время интересует меня в процессе разработки программного обеспечения.

Хочу поделиться с хабросообществом тем, что я вынес из книг и с чем приходится сталкиваться в реальности.

Теория

Continuous Integration (далее CI) — это практика разработки программного обеспечения, в которой члены команды проводят интеграцию не реже чем раз в день. Результаты интеграции проверяются автоматически, используя автотесты и статический анализ кода.

Использование CI позволяет вовремя отслеживать ошибки интеграции, сделать систему и процесс разработки более «прозрачными» для всех участников команды, также, CI избавляет от рутинных операция по сборке продукта, повышает качество продукта, включает в себя профит от написания тестов, который, я думаю, для всех хаброюзеров очевиден.

Фактически, CI позволяет избавиться от предположений, при процессе разработки ПО. Менеджер предполагает, что продукт готов и стабилен, программист — что в коде нет ошибок и т. д. Избавиться от вопросов, таких как: «стабильна ли последняя сборка, какие фичи готовы, соответствует ли код стандартам компании» и т.д.

Всех, кому интересна тема CI прошу под кат.

Хотите стать тестировщиком с мировым именем? Тогда спросите, как это сделать, у человека, который уже достиг таких высот. 20 апреля в Москве пройдет тренинг одного из самых известных во всем мире специалистов по тестированию программного обеспечения – Майкла Болтона, имеющего 25-летний опыт успешной работы в данной сфере.



В преддверие своего московского визита Майкл Болтон дал эксклюзивное интервью и рассказал о том, какие мифы существуют в сфере тестирования ПО и почему важно их воспринимать правильно, а также затронул тему того, что ожидает участников на тренинге «Критическое мышление для тестировщиков», который пройдет 20 апреля в Москве.

Последнее время я часто сталкивался с разработкой на Ruby и Ruby on Rails. О них говорить я не собираюсь. Но после возвращения к PHP кое-чего стало очень не хватать. Одна простая утилита, оказавшаяся отличным помощником для любого разработчика, который использует тесты. autotest запускает тесты на любое изменение в кодовой базе или тестах. Я попробовал поискать в Гугле и на Гитхабе аналог для PHP. Все решения, которые я нашел, были написаны либо на Ruby, либо на серверном JavaScript, либо на bash (хотя позже все же нашел решения и на PHP, которые, тем не менее, мне не понравились по разным причинам). Я являюсь сторонником мнения, что утилиты для разработки на каком-то языке должны быть написаны на нем же. Причин тому много, одна из наиболее значимых лично для меня — это возможность легко и непринужденно вносить какие-то правки и изменения в код самой утилиты (например, когда разработчик утилиты не реагирует на баг-репорт). Руки у меня зачесались, и я попробовал написать свою версию autotest для PHP. Результат можно посмотреть на Гитхабе.

Добрый день, Хаброчитатели!

В своей рубрике IT (Interesting Testing) я постараюсь рассказывать вам о разных интересных подходах к тестированию и полезных инструментах, делающих процесс поиска ошибок захватывающим.
Сегодня я расскажу вам о:

• BFT – Business Flow Testing, что это?
• На простых примерах покажу как этим пользоваться
• Какие есть преимуществах у такого подхода
• Где его можно применить
• И что будет дальше

Потоковое тестирование (BFT — BusinessFlowTesting)

BFT – это подход к тестированию, где вы смотрите на продукт не с точки зрения конкретных кейсов, а с точки зрения поведения системы в каждой ее точке.

Многие JavaScript-фреймворки предлагают свое представление о том, как должен выглядеть код. Более того, речь идет не просто о стиле, речь идет о способе написания сценариев. Это обусловлено практически абсолютной демократичностью JavaScript, да-да, именно таким является мультипарадигменный язык с С-подобным синтаксисом, прототипным наследованием, динамической типизацией и реализацией разнящейся от браузера к браузеру. Поэтому, когда речь идет о test-driven JavaScript я понимаю, что речь идет не просто об особом стиле программирования, но об особых технических принципах для особого фреймворка позволяющего тестировать JS приложения.

В этой статье я буду спорить сам с собой что же из себя представляет тестопригодный JavaScript-код и в какую цену он обойдется, ежели его начать использовать.

Внимание: длиннопост.

Оригинал: www.infoq.com/articles/atdd-from-the-trenches

ATDD с передовой

Разработка через приемочное тестирование для начинающих

Если вы когда-нибудь бывали в такой ситуации:

Тогда эта статья для вас — конкретный пример того, как начать разработку через приемочные тесты (Acceptance-test driven development) в действующих проектах с легаси кодом. В ней описан один из способов решения проблемы технического долга.
Это пример из реального проекта, со всеми изъянами и недостатками, а не отполированное упражнение из книги. Так что надевайте свои берцы. Я буду использовать Java и JUnit, без всяких модных сторонних библиотек (которыми, как правило, злоупотребляют).
Предупреждение: Я не утверждаю, что это единственный Правильный Путь, существует много других “стилей” ATDD. Так же в этой статье не так много чего-то нового и инновационного, здесь просто описаны хорошо себя зарекомендовавшие подходы и опыт из первых рук.

Недавно в нашей фирме устроили лекцию «Engineering Practices» и это оказалось введением в TDD.
О нет, только не это! «Иногда они возвращаются» (с) Стивен Кинг

На прошлой работе мы потратили 3 года на попытку внедрить эту методику. Это было мучительно. Менеджмент искренне верил в то, что TDD решит проблемы фирмы. Реальность разительно несоответствовала этому. Все это будило затертые воспоминания о Советской эпохе. Вспоминались висящие на стенах плакаты «Вперед к победе коммунизма» и фразы вроде «Учение Маркса всесильно потому, что оно верно».


Так что же не так в консерватории c TDD?

Трудно одним заголовком сформулировать, чем же является Galen Framework. Все началось с того, что у меня возникла потребность тестировать сайты в различных браузерах и проверять: не поехала ли разметка, например, в том же Internet Explore или Chrome. Затем возникла мода на Responsive Web-Design, и пришлось вручную менять ширину браузера и проверять, как отображаются сайты. И, хотя все это время были WebDriver и Selenium Grid под рукой, так и не получалось нормально тестировать верстку сайта в Java коде. Одна из идей была: делать скриншоты в разных браузерах в Selenium Grid и затем собирать их все в один большой отчет, по которому один из тестировщиков обязан пробежаться глазами и, в случае обнаружения несоответствий, рапортовать о дефекте. К сожалению, вся эта затея долго не продержалась. Тестировщикам стало лень листать огромный отчет и сравнивать скриншоты, и они все равно пропускали мелкие дефекты. А затем пошли требования внедрения во всех сайтах Responsive Design. И вот тут появился Galen Framework. Решение оказалось простым: проверять размер и расположение элементов относительно друг друга. Для этого понадобился специальный язык Galen Specs, который было бы легко читать и понимать.



Если коротко, Galen Framework — это специальный язык и инструмент для тестирования отображения сайта в браузере. Он позволяет тестировать адаптивный дизайн, а также проводить кросс-браузерное тестирование сайта.

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

Сразу оговорюсь, что примеры приводятся применительно к языку C# и платформе .NET. Соответственно, в других языках/платформах подходы и реализации могут отличаться.

Итак…

Некоторое время назад я принял решение потихоньку внедрять в свою практику автоматизированное тестирование и TDD. Признаюсь честно, получалось все это с переменным успехом. Но то, что жить стало гораздо интереснее – это неоспоримый факт. Со мной стали происходить разные приключения. И, как во всех приключениях, иногда становилось немного страшно. Об одном таком случае я и хочу рассказать.

В проекте, в котором я принимал участие, потребовалась плотная работа с временными интервалами от минуты до года. Плох (или наоборот слишком хорош) программист, не написавший в своей жизни ни одну библиотеку работы с датами. Я не хуже и не лучше других, поэтому решил размять мозги и создать немного кода.

Продолжение. Начало здесь.

Как все это использовать?

Хороший вопрос. Мы остановились на том, что TDD помогает четко определить границы текущей задачи, дает простой способ одновременной работы с мелкими деталями, относящимися к проблеме, и предоставляет быструю обратную связь с кодом, сообщая, насколько удачно получившееся решение. Именно эти факты помогут нам преодолеть трудности в изучении этой техники.

От переводчика: так сложилось, что в русскоязычном интернете мало информации о TDD и в основном описываются механические действия разработчика. Главному же – идее – уделяется совсем мало внимания. Эта статья является попыткой восполнить этот пробел. Важно отметить, что она не для тех, у кого нет времени на тесты, и тем более не для тех, кто не осознает важность слабосвязанной архитектуры. Статья (оригинал) адресована тем, кто делает или собирается сделать первые шаги в TDD.

Я все больше в своей практике пытаюсь использовать автоматизированное тестирование. Стараюсь при этом не плодить инструменты и библиотеки, обходиться простыми подходами. Не так давно, я задумался о том, как протестировать CSS-файлы. Поиск по Интернету выявил следующие точки зрения на этот вопрос:

1. Тестирование CSS не имеет смысла, так как это декларативный язык, а его результатом является сверстанное изображение страницы, которое можно оценить лишь визуально.
2. Протестировать CSS можно с помощью снятия битмапов с сгенерированной страницы и сверка ее с эталонным изображением. Для этого даже есть некоторые инструменты.
3. Нашлась некоторая библиотека CSS-Unit.

Должен сказать, что все варианты мне не понравились. В конечном итоге мне удалось протестировать CSS используя текстовый редактор, Firefox + Selenium IDE и… и больше ничего.