пожалуйста, разобраться. Сейчас допиливаю за другим челом npm модуль (плагин для другой библиотеки). Этот модуль написан на typescript, но довольно плохо (много неявных any, strict mode у tsc не включён, структуры кода никакой - отдельные функции размазаны по всей кодовой базе вперемешку с классами). Начал писать к нему unit тесты так же на typescript, но в этот момент осознал важную вещь: тестируя typescript код в данном случае я тестирую то, чего не будет существовать. Объясню свой ход мыслей:
1) Все типы данных, интерфейсы, типы аргументов и возвращаемых значений функций и методов просто перестанут существовать после компиляции в js
2) Т.к. в коде много неявных any, то я не уверен, что typescript отловит все случаи несовпадения ожидаемого типа с фактическим
3) Данный код, в силу того, что он является npm модулем, может быть использован людьми, которые не используют typescript вообще (чистый js, или dart, или ещё что). Соответственно, даже если сделать файлы деклараций, то это не означает, что люди, использующие этот модуль, будут передавать в функции и методы значения тех типов, которые описаны в декларационных файлах. При этом из-за того, что сам npm модуль и, как следствие, тесты к нему написаны на typescript, то я просто не могу протестировать все эти случаи.
Я вижу один выход из этой ситуации: сначала компилировать в js, а потом тестировать именно скомпилированный модуль, либо по частям, либо весь целиком. Подскажите, что вы думаете по этому поводу?
абсолютное большинство не делает так как то что вы называете выходом из ситуации
в тс идет рассчет на минимизацию рантайм проверок в том числе
вы забыли еще как минимум один вариант - писать тесты на тайпскрипт, а там где вы тестируете вещи, которые передаются "не того типа" - глушить ошибку в тестах с помощь ts-expect-error
Точно ведь. Совсем забыл про это. Большое спасибо
Обсуждают сегодня