status
, используйте фильтр present
, например (status=*)
. status
атрибут, отмените текущий фильтр: (!(status=*))
. status
индексирован для equality
и presence
. Если у вас нет доступа к этой информации, проверьте с помощью администраторов LDAP в соответствующей организации. Большая часть кода моей библиотеки C может быть скомпилирована с -DTEST
, чтобы раскрыть main()
(и часто некоторые вспомогательные функции тоже) в исходном файле с реализацией. Поэтому, если у меня есть набор функций, объявленных в source.h
и определенных в source.c
, то source.c
может выглядеть следующим образом:
#include "source.h"
#include …other headers…
…code defining functions declared in source.h
#ifdef TEST
#include <stdio.h>
int main(void)
{
…test code…
}
#endif /* TEST */
Это работает, когда набор тестов достаточно мал, чтобы поместиться в исходный файл. Если тесты становятся больше, чем код, тогда я создаю один или несколько отдельных исходных файлов, содержащих тестовый код. Каждый из этих файлов может иметь свои собственные main()
, или они могут быть спроектированы так, чтобы быть связанными вместе - в зависимости от того, что кажется более удобным.
Что уместно, зависит от размера и сложности тестов. Некоторые функции заканчиваются фиксированными - жесткими - тестами; некоторые тратят время на чтение данных со стандартного ввода; другие обрабатывают списки аргументов, если они предоставляются, и используют минимальный тест, если аргументов нет. Тестовый код может использовать инфраструктуру модульного тестирования или может быть более или менее специальным, опять же, в зависимости от сложности (и древности) кода.
Вы можете поместить большую часть своего кода в общую библиотеку.
После этого у вас будет исходный файл с вашей «обычной» функцией main
, который сам компилируется в исполняемый файл и использует общую библиотеку. Затем вы можете написать отдельную тестовую программу, которая также ссылается на библиотеку и может выполнять различные необходимые тесты.