chabapokЕсть программа, которая создает таймера через вызов timerfd_create, регистрирует их в селекторе (в том же селекторе сеть), устанавливаем им время срабатывания и делает вызов poll() или select() или epoll()


Блин, эпик фейл. POLL на таймере...

Как такое тестировать, если надо такое просто выкинуть?

Если серьёзно говорить о такой хрени, то естественно, такое не надо вообще тестировать .
Надо тестировать фукнционал, который вызывается по таймеру, а сам таймер тестировать бессмысленно.
Если он не будет приходить, а ты знаешь, что сам функционал работает, потому что оттестирован,
тебе останется в программе только добиться срабатывания этого таймера.

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

chabapokДа кто ж спорит, что фейл. Вопрос в том, как сделать правильно.

MasterZivТебе нужно тестировать функциональность, которая будет вызываться по событию, а не появления событий.
разумеется, и это нужно. Но бывают определенные баги, которые завязаны имеено на связку различных компонентов системы.

впринципе, я придумал, как такое можно тестировать. И линкера есть функция --wrap=symbol, а еще есть LD_PRELOAD. Это позволяет перехватывать любые вызовы.
Я буду перехватывать timerfd_create, создавать вместо таймера пайп и возвращать его. Приложение будет думать, что ему возвратили id таймера, а на самом деле это будет пайп. timerfd_settime тоже должно перехватываться, и тестер будет понимать, что с таким-то пайпом сопоставили такой-то таймаут, и в нужный момент он запишет в пайп 8 байт - это разбудит poll.

А нафига?
Не проще ли просто написать в тесте имитацию прихода нужных событий в нужном порядке?