LINUX.ORG.RU

Декларативная система тестирования процессов ОС уровня системных вызовов

 , , , ,


0

2

У меня возникла мысль.

Актор это удачная абстракция. Компьютеры в сети ведут себя как акторы. Устройства в компьютере ведут себя как акторы. Процессы ОС тоже акторы. Процессы Эрланга тоже акторы.

У актора своя память, протокол обмена сообщениями.

Окей.

---

1) Люди взяли процесс ОС за единицу композиции, и стали строить распределённые системы: контейнеры, кубернетис, и всё такое.

Более громоздко чем процессы Эрланга, зато отлично можно интегрировать легаси, приложения написанные на хер пойми чём хер пойми когда.

Окей.

---

2) И тут и там полезли ИИ сервисы генерящие код: Github Copilot, Codeium и подобные. Неплохо генерят код для решения изолированных задач, когда не нужно изобретать чего-то радикально нового. Пока не очень разбираются в существующих системах и не очень умеют связывать их между собой.

На что бы ни стали способны ИИшки, формулировать КАКИМ ИМЕННО должно быть поведение программы всё равно нужно человеку. Машина не будет за нас формулировать смыслы.

Окей.

---

Если скрестить 1) и 2), то напрашивается очевидное:

Раз мы умеем генерить код для изолированных задач, и раз процесс ОС с помощью контейнеров стал универсальной единицой композиции распределённых систем, то разве не разумно было бы сделать систему тестирования процессов уровня системных вызовов? Language/Runtime-agnostic.

Т.е. пишешь декларативные тесты на уровне конкретных данных что должны быть отправлены/получены в сокет/файл. В терминах системных вызовов которые должен или не должен сделать процесс ОС.

Т.е. строишь приложения, собираешь библиотеку (глюкотеку) багов и разных входных данных от пользователей. Превращаешь их в тесты. Все семантика, смысл твоей системы, описывается тестами.

И уже под тесты ты либо пишешь код, либо копируешь чужое и криво-косо интегрируешь, либо вообще генеришь ИИшкой. Код становится расходных строительным материалом, на него плевать. Главное чтобы смыслы в тестах были переданы правильно.

★★

Последнее исправление: vladimir-vg (всего исправлений: 1)
Ответ на: комментарий от anonymous

Это может:

  • ускорить разработку, переложить написание части кода на ИИ
  • упростить миграцию между разными рантаймами и языками
  • упростить делегирование разработки отдельных частей приложения
vladimir-vg ★★
() автор топика

То что вы описываете называется TDD (Test Driven Development) вид сбоку. Этот подход умер во время ковида, так совпало. Его суть в уходе от ответственности за качество своего кода. Какая разница какой он если тесты проходит. Этим любят баловаться всякие рубисты из города-реки.

Главный минус: невозможность полного покрытия тестами т.к. нет этапа проектирования. Для бизнеса это еще и сильное увеличение времени разработки.

Лучше автоматизированного регрессионного тестирования по соотношению качество/скорость разработки еще ничего не придумали.

Obezyan
()

О, Володя, как дела? MVP хоть собери, а так не понятно пока какую проблему ты решаешь. Чтобы не платить программистам, концепция nocode выглядит лучше твоей, нанять пару нонеймов или нанять еще програмистов которые напишут тесты.

hizel ★★★★★
()

никто не пишет в бизнес-коде сисколы, все они случаются на уровне libc, компилятора etc. Соответственно, никакого отношения к логике программы такие тесты иметь не будут. Разве что мы тестируем системный софт, но тогда это просто юнит-тесты.

phoenix ★★★★
()
Ответ на: комментарий от hizel

MVP хоть собери, а так не понятно пока какую проблему ты решаешь.

Это понятно. Просто хотел услышать мнения. Вдруг это всем очевидно, уже пробовали и выбросили.

vladimir-vg ★★
() автор топика
Ответ на: комментарий от ugoday

У вас неявное предположение, что написать тесты проще, нежели написать программу.

Да, есть такое предположение.

Вродеж тест это просто сценарий коммуникации между разными компонентами. Если реальное выполнение совпадает со сценарием, значит тест пройден.

Тут вроде не должно быть ничего сложного.

vladimir-vg ★★
() автор топика

Код становится расходных строительным материалом, на него плевать. Главное чтобы смыслы в тестах были переданы правильно.

И в итоге получим нечто ни черта полезного не делающее, но тесты проходящее. Впрочем, большая часть гуглоплея подобным и забита.

rebforce
()
Ответ на: комментарий от rebforce

И в итоге получим нечто ни черта полезного не делающее, но тесты проходящее.

Как только вводится формальная метрика, которой пытаются измерить качество или эффективность системы, работа системы начинает оптимизироваться по этой метрике, но отнюдь не пока качеству или эффективности.

Этот эмпирический принцип в науке как-то называется, но я не могу вспомнить.

wandrien ★★
()

И уже под тесты ты либо пишешь код, либо копируешь чужое и криво-косо интегрируешь, либо вообще генеришь ИИшкой. Код становится расходных строительным материалом, на него плевать. Главное чтобы смыслы в тестах были переданы правильно.

Поздравляю, вы изобрели TDD.

Эта серебряная пуля ничем не отличается от всех остальных серебряных пуль.

wandrien ★★
()
Ответ на: комментарий от vladimir-vg

Вродеж тест это просто сценарий коммуникации между разными компонентами.

Лучший способ понять что программа должна делать: это написать её. А можно было бы заранее подумать как и из чего должны состоять ваши компоненты и какими данными обмениваться … всё б тогда совсем по другому было бы.

ugoday ★★★★★
()
Ответ на: комментарий от Obezyan

Главный минус: невозможность полного покрытия тестами т.к. нет этапа проектирования.

проектирование возможно на каждой итерации разработки, собственно говоря в этом и соль TDD, а сами тесты - это побочный эффект разработки, а не самоцель. Естественно, TDD никак не отменяет всех остльных видов тестирования, автоматизированного и/или ручного.

seiken ★★★★★
()
Ответ на: комментарий от vladimir-vg

Вродеж тест это просто сценарий коммуникации между разными компонентами. Если реальное выполнение совпадает со сценарием, значит тест пройден.

Угу. В программе что-то вроде

char *query = "SELECT * FROM your_table_name";

// Submit the query and retrieve the result
PGresult *res = PQexec(conn, query);

Попробуй написать ожидаемые системные вызовы для теста этой программы.

monk ★★★★★
()