Мене трішки довели хайпом навколо перепису Bun на Rust. Я вирішив подивитися що це означає на практиці.

Я не буду робити ніяких висновків, лише зроблю акценти які мені здається важливими, та дам числа для діскусії.

Коміт де відбулися зміни це https://github.com/oven-sh/bun/commit/23427dbc12fdcff30c23a96a3d6a66d62fdc091d . Для початку я швидко вирішив подивитися що було із тестами. В Bun я бачу лише інтеграційні тести в репозіторі. Ці інтеграційні тести мають наступні характеристики.

18 610 тестів існує. Мабуть справжне число на декілька тисяч більше, бо я рахував грепом, а не в рантаймі.
1546 файлів із тестовими групами (тобто де в принципі описані тести)
3582 тестових групп (describe).

ще вони запускають тести від https://github.com/elysiajs/elysia. Це

1 581 тестів додатково.
130 файлів із тестовими групами (тобто де в принципі описані тести)
151 тестових групп (describe).

Сумарно 20 191 існує тестів.

630 690 рядків Zig було (на 100 менше до переписування). Стало 899 067 рядків Rust

Що дає щільність покриття коду тестами.

  • в Zig було 1 тест на 33 рядків коду
  • в Rust стало 1 тест на 44 рядків коду

Для порівняння в NodeJS

8 015 всього тестів існує.
1 026 файлів із тестовими групами (тобто де в принципі описані тести)
3 267 файлів які самі є тести.
  • 138 759 рядків JS
  • 108 782 рядків C++

Сумарно 247 541 рядків коду.

Щільність покритя коду 1 тест на 30 рядків.

Також треба враховувати що Bun це рантайм. При тестуванні надійності рантайму мало прогнати тести, ще важливо щоб рантайм коректно вів себе на всіх кінцевих продуктах. Це взагалі не проблема зазвичай у прикладних продуктах. Для них важливіше мати лише інтеграційні тести. Скоріш за усе важливо скільки рядків коду виконує рантайм при запуску конкретних тестів кінцевих продуктів. Найближчий приклад із корпоративного світу на мою думку це розробникі фреймворків та платформ команди із дуже строгою системою обратної сумісності щодо своїх продуктів.

Також на мою думку важливо при зміні реалізації мати набагато більше тестів ніж для звичайної еволюції продуктів, бо при еволюції ти менше міняєш, і менше шансів мати велику кількість незареестрованих нових поведінок яка ніж неприємні кінцевому кліенті ніж при більш великим кускам змін.

Чи цього достатньо для контролю 900 тисяч нових рядків чи ні в цьому продукті я думаю вирішувати вам. Будьте зважені коли намагаєтесь досягти аналогічних результатів у себе на проекті.