и с тестами, тогда у нас есть доступ к внутренней реализации модуля (императив), а не только к API модуля (декларатив). В статье нас призывают к TDD, при этом не спускаясь на императивный уровень, а формулируя тесты перед кодингом только на декларативном уровне. Но при рефакторинге я предпочёл бы иметь покрытие на императивном уровне. В наше время этого легко добиться с помощью ChatGPT. Тогда такие императивные модульные тесты не жалко выбрасывать вместе с модифицируемым кодом, если потребуется. Хорошо. А как бы улучшить Developer Experience для декларативных модульных тестов? Сплю и вижу процесс разработки по схеме: Event Modeling + BDD > Integration/Unit Tests (via gherkingen) > tests-first development for external API of modules > Unit Tests Coverage for internal functions in modules (via ChatGPT).
Кто-нибудь об этом думал? Отговорите или поделитесь опытом. 🙃
по теме: main.go > package main main_test.go > package main тогда есть доступ к непубличным переменным
Обсуждают сегодня