Процесс выполнения задачи.

Описание плана, написаня тестов и проектирования(отложено)

• План написан под Ubuntu. Реализация плана на 3-4 ноября

Релиазовать план будет слишком затратно(много тонкостей). Пишу парсер для конкретной разметки.

Напишите процессор простого markdown-подобного языка разметки.

Описание языка, он же пример файла с разметкой.

Описание намеренно сделано не полным. Вы должны сами придумать наиболее удачное поведение вашего процессора во всех спорных случаях. Все ваши решения должны быть зафиксированы в виде модульных тестов.

Создайте консольное приложение, принимающее в качестве аргумента имя исходного файла в markdown-подобной разметке, и генерирующее в директории программы html-файл, полученный после процессинга исходного файла по описанным правилам.

Создавая процессор этого языка работайте в режиме TDD.

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

• Пишите тесты так, чтобы их имена читались как спецификация на язык разметки! У вас должна получиться более точная и полная спецификация, чем в файле sample.txt.
• Уделите внимание правильному порядку тестов. Упорядочте их так, чтобы их было удобно читать как спецификацию.
• Каждый тест должен быть в формате Arrange—Act—Assert.
• Не разрешайте себе более одной проверки на тест. Это упростит придумывание названий для тестов. Удержитесь от проверки сразу всего-всего-всего. Тест — пункт спецификации. Значит и проверять нужно только один пункт спецификации

Сделайте fork этого репозитория и ведите всю работу в нем.

Разбейте работу на отдельные подзадачи и делайте по отдельному коммиту на каждую подзадачу.

Старайтесь не смешивать массовые механические и содержательные правки. Например, добавление функциональности и массовые переименования должны быть в разных коммитах.