Комментарии 5
Поздравляю, вы написали предельно бесполезный тест максимально сложным способом, который генерирует 100500 сложных объектов, содержимое которых никак не используется. Впрочем, с юнит-тестированием всегда ерунда выходит. Гляньте, для сравнения, осмысленный компонентный тест, который исполняется всего за пол миллисекунды прямо на проде:
'task add'( $ ) {
const app = $hyoo_todomvc.make({ $ })
const rows = app.task_rows()
const title = $mol_guid()
app.Add().value( title )
app.Add().submit()
const task = app.task_rows().at(-1)!
$mol_assert_equal( task.title(), title )
$mol_assert_equal( task.completed(), false )
$mol_assert_equal( app.task_rows(), [ ... rows, task ] )
$mol_assert_equal( app.Add().value(), '' )
},
Тест прямо на проде? Ок, допустим. А какие тесты у вас выполняются до прода?
Меня прямо-таки умиляют такие пассивно-агрессивные поздравления... Спасибо, конечно, но я всё же порекомендовал бы Вам внимательнее взглянуть на статью: речь тут идет о unit-тестировании. О каких unit-тестах вы говорите на проде? В runtime? Так это уже совершенно другое. Unit'ы используются для тестирования в процессе разработки и для проверки приложения перед деплоем. Любые тесты на живом приложении имеют дело с совершенно другим контекстом и, в большинстве случаев, не должны опираться на рандомные подделки.
Что касается теста... Так статья вроде не про написание самого красивого и умного теста, а просто пример того, как могут быть созданы некие рандомные объекты.
Спасибо, конечно, но я бы вам рекомендовал ознакомиться с фрактальным тестированием, где одни и те же тесты выполняются и во время разработки, и после сборки, и перед деплоем, и после деплоя, и на стейджинге, и на проде, и на мобилке, и на микроконтроллере, и в хроме, и в лисице, и в виндоус, и в линукс, и на x86, и на arm, и на nvidia, и на amd.
Тестовые данные в TypeScript: вызовы, решения и мой опыт