[юнит-тестирование] Как проверить, что программа уходит в фон или не уходит в него по указке

не знаю, как это делают гуру ТДД, сам им не увлекаюсь, но я бы проверял наличие управляющего терминала - у демонов его нет. еще он скорее всего будет лидером группы процессов. можно как изнутри, так и с наружи.

Кстати о гуру ТДД.

Скастовать сюда бы baverman. Проект-то на питоне, использует python-daemon для демонизации.

Это уже функциональное тестирование. И нужность этого теста несколько сомнительна, так как код для поднятия окружения и проверки корректности будет сильно больше самой обертки, причем, если схалтурить, то вся эта конструкция будет еще и хрупкой.

Но если бы делал я, то предусмотрел передачу фиктивного параметра, по которому демон можно было бы идентифицировать в списке процессов, а там уже pgrep. И собственно все, программа стартовала, терминал отдала, процесс есть — значит демон.

Можно пойти еще дальше, в демоне обрабатывать какой-нибудь ненужный сигнал (USR1, USR2), а изнутри уже гораздо легче определить правильно задемонизировался процесс или нет (кто родитель, есть ли терминал, куда смотрят ввод/вывод) и сбрасывать эту инфу в определенное место.

Или, если интересны только линуксы, можно просто шерстить /proc.

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

Что-то я загнал. Делается маленький сервер, слушающий пайп, с помощью которого обертка легко и непринужденно проверяется на работоспособность.

Как проверить, что программа уходит в фон или не уходит в него по указке

тебе надо создать при помощи mock чучелко из куска кода, который реально занимается уводом в фон твоей программы, подсунуть это чучелко своему куску программы и послушать что от твоей программы прилетает - если правильно (с правильными параметрами и в нужной последовательности) всё вызываются - гуд, нет - кричи караул

для mock'ов мне больше нравится pymox

Делается маленький сервер, слушающий пайп, с помощью которого обертка легко и непринужденно проверяется на работоспособность.

не TDD

не TDD

А это и не должно быть им. Здесь надо не логику проверять, а состояние внешнего мира, поэтому моками не обойдешься.

> не TDD

А это и не должно быть им.

Решил один проектик построить полностью по TDD.

?

Здесь надо не логику проверять, а состояние внешнего мира, поэтому моками не обойдешься.

тогда это уже не модульное тестирование

Решил один проектик построить полностью по TDD.

?

Скорее всего, имелись ввиду тесты, любые.

Имелось в виду, что сначала всегда тест, и только потом код.

сначала всегда тест, и только потом код.

Как заметил, shty, можно подсунуть мок. Но тогда непонятно, что вообще тестируется. Одной из особенностей TDD, является возможность подменить имплементацию без ущерба для тестов. И TDD хорошо работает, когда тестовое окружение минимально или его вообще нет.

Здесь нам конкретно надо проверить, поднялся процесс или нет. О того что тест напишется первым, ни холодно ни жарко.

Но тогда непонятно, что вообще тестируется.

Это нормально для TDD.

:3

Как заметил, shty, можно подсунуть мок. Но тогда непонятно, что вообще тестируется.

Надо убедиться в том, что реакция на ключ --daemon правильная.
Пока что думаю в сторону процесса, который садится на юниксовый сокет и отдает в него что-то. Нужно запустить процесс как демон и убедиться, что он откликается на позывные и (отдельно) его pid-файл лежит там, где ему сказали лечь.

Можно еще подделать модуль daemon и проверить, что происходит вход в контекст и что контексту переданы правильные параметры.

Хе-хе. Есть такое дело.

Используй mock objects