Comments 4
Может, я не понял чего, но сборщик проектов работает с неким файлом описания проекта и собирает проект согласно ему. Дочитал до какого-то теста, до каких-то BuilderFactory, jar'ов и прочих модулей и классов, хотя не сказано ни слова, что за язык предполагается использовать для описания проекта и хотя бы самые общие черты будущего сборщика. Как-то очень странно такое читать, дальше просто не стал.
Во втором абзаце:
Зачем понадобилось писать велосипед, когда уже существуют Maven и Gradle? Конкретной причины нет, мне просто нравится писать код.
Это, кстати, вернейший путь к провалу проекта. Ничего не имею против попытки создать сборщик, ни один из существующих не идеален, но потребности должны быть учтены в первую очередь.
Скажем, мы хотим файл проекта как у мавена, т.е. статический, но более читабельный для человека, и чтобы писать было проще. Чтобы его можно было обрабатывать любым инструментом, и не требовалось выполнять код сборщика, чтобы получить скажем список зависимостей.
Насколько это реально полезно - вопрос второй, но сразу возникает вопрос первый - вот команда мавена в свое время (причем очень давно) сделала проект полиглот, с теми же примерно целями. И много вы видели файлов, написанных в синтаксисе, отличном от штатного pom.xml? Я - ни одного. То есть, даже если такая потребность и была, она настолько несущественна, что никто этим не пользуется.
Спасибо большое за статью, очень здорово видеть ТДД, и кажется очевидным, что это делает код чище.
В имплементации же многое можно улучшить. Разница между given и when в том, что одно предусловие, а второе условие, и если предусловия мы принимает как есть, то в условии мы проверяем все кейсы, в этом сила конвенции.
Ну, скажем, вот у вас куча отдельных given'ов и одинаковые when'ы. Тут должно быть что-то вроде
givenModuleAndFactoryAndTempDir - потому что вы полагаетесь на их существование,
whenDependencyExcluded - а тут мы проверяем все случаи
Или вот еще пример
Тут тоже явно перебираются условия в given.
Ну и когда я вижу условия, я автоматически начинаю искать пропущенные - где все корнер-кейсы-то, т.е. пустые и несуществующие папки, пустые или некомпилируемые файлы, частично компилируемые файлы и т.п.?
Если же вы все это уже проверили в других местах, значит это предусловие и должно быть обозначено в given.
Сила ТДД в том, что можно посмотреть на тесты и понять, как должен вести себя код и что пропущено, - но из этих тестов этого пока не понятно.
(Слова типа Is, Are можно опускать в заголовках и тестах, они не нужны).
Как создать свой сборщик проектов