По сути, есть часть "Class", которая должна быть переносимой и не всегда использоваться с компилятором замыкания. Некоторые конструкторы проверяют отсутствующие параметры и выдают исключение. Затем часть приложения, реализующая класс, который должен быть более закрытым. Базовый c тестовый фреймворк проверяет, что исключение действительно генерируется. Система сборки (также базовая c) объединяет все и запускает ее через компилятор замыкания с расширенными оптимизациями.
Тесты вызывают JSC_WRONG_ARGUMENT_COUNT предупреждений. Это не очень сложное приложение, и кажется желательным иметь возможность компилировать его с 0 ошибками, 0 предупреждениями.
Я вижу шесть способов справиться с этим, но у каждого есть недостатки. Есть ли способ лучше? Можно ли что-нибудь из этого сделать лучше?
1. Жить с предупреждениями
Вероятно, мой наименее любимый, но они являются только предупреждениями в конце концов. Моя главная проблема в том, что вы, скорее всего, не заметите предупреждение, которое вас волнует. Я мог бы сделать что-то сделанное на заказ в системе сборки, чтобы тихо подавить эту точную ошибку, но это кажется сложным (и поэтому fr agile)
2. Потеряйте эти тесты и доверьтесь GooCloCom
Это было бы хорошо, если бы я не хотел, чтобы класс можно было повторно использовать без GooCloCom. Я всегда мог их закомментировать и, надеюсь, не забыть восстановить, если я повторно использую или выпущу Класс публично.
3. Отметить необязательные параметры
Это исправляет предупреждения, но за счет того, что мой не тестовый код больше не проверяется
5. Подавить предупреждения
было бы идеально, но если я все неправильно читаю, это невозможно: предупреждения о количестве параметров не отображаются в списке подавляемых предупреждений
6. Разбейте модульные тесты и не включайте их при компиляции для производства
Это может быть лучшим решением, которое я могу придумать (обратите внимание, что тесты уже не заканчиваются в производственной сборке потому что они находятся внутри блока if (!PRODUCTION), но они генерируют предупреждения до того, как компилятор их выбросит, к сожалению). Но это все еще означает, что предупреждения появляются в других сборках (которые я могу игнорировать, но рискую пропустить важные другие предупреждения)