Рефакторинг тестовых источников

Скажем, при первой сборке все экземпляры fread должны оставаться прежними. Затем при второй сборке все экземпляры fread должны быть заменены на getline, а затем на mmap_getline() и так далее.

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

testbit.chchc

/* don't know if this works: might need another layer of macro */
#include "../src/" #TESTME ".c"

void test_ ## TESTME ## _success(void) {
    FILE *const fp = fopen("test/sample.txt", "r");
    FileBuf fbuf = {};

    TEST_CHECK(TESTME(fp, &fbuf));

    fclose(fp);
}

TEST_LIST = {
    { "test_" #TESTME  "_success", test_ ## TESTME ## _success },
    { nullptr, nullptr },
};

testall.c

#define TESTME readlines_fread
#include "testbit.chchc"
#define TESTME readlines_getline
#include "testbit.chchc"
/// ...

Этот код в том виде, в каком он написан, довольно бессмысленен (определение TEST_LIST столько раз определенно является какой-то ошибкой), но общий подход верен.

Если у вас есть макрос, который расширяется и выглядит как имя заголовка, вы можете использовать:

#include INCLUDE_FILE_NAME

Итак, вы можете скомпилировать с помощью -DINCLUDE_FILE_NAME='"../src/readlines_fread.c"'.

Линия:

{ "test_readlines_fread_success", test_readlines_fread_success },

можно преобразовать для использования макроса:

{ FUNCTION_NAME_AND_POINTER(test_readlines_fread_success) },

с:

#define FUNCTION_NAME_AND_POINTER(name) #name, name

Непонятно, как используется объявление массива TEST_LIST — похоже, оно объединяет тип с каким-то именем массива. Честно говоря, это скорее сбивает с толку, чем приносит пользу. Лучше было бы разделить на:

TEST_ARRAY_TYPE Test_Array_Name[] =
{
    …
};

Однако во многих отношениях это конкретное наблюдение является косвенным, но мой тестовый код будет использовать эту измененную нотацию.

В вопросе не очень ясно, какие имена являются «именем функции». Кажется, есть много мест, в которые встроены различные вещи, которые могут быть «именем функции». Если FUT (тестируемая функция) равна readlines_fread, то среда сборки может выполнить за вас значительную часть работы.

Вот версия вашего файла с некоторыми макросами, которые предположительно будут помещены в заголовок, вероятно acutest.h для использования в производстве. Мой источник находится в test97.c.

/* SO 7856-3912 */

//#include <assert.h>
//#include <stdio.h>
//#include <string.h>
//#include "acutest.h"
//#include "FileBuf.h"

/* Check configuration */
#ifndef INCLUDE_FILE_NAME
#error You must define INCLUDE_FILE_NAME as the name of the source file to test
#endif /* INCLUDE_FILE_NAME */
#ifndef FUNCTION_UNDER_TEST
#error You must define FUNCTION_UNDER_TEST as the name of the function under test
#endif /* FUNCTION_UNDER_TEST */

#include INCLUDE_FILE_NAME

#define TEST_FUNCTION_NAME(name)    test_ ## name ## _success
#define TEST_FUNCTION(name)         TEST_FUNCTION_NAME(name)

#define TEST_ARRAY_ENTRY(name)      #name, name
#define TEST_ARRAY_EXPANSION(name)  TEST_ARRAY_ENTRY(name)
#define TEST_ARRAY_MAPPING(name)    TEST_ARRAY_EXPANSION(TEST_FUNCTION(name))


void TEST_FUNCTION(FUNCTION_UNDER_TEST)(void)
{
    /* The lines and line lengths are at most 1024 in sample1.txt. */
    char buf[1024];
    char *lines[1024];
    size_t line_count = 0;
    FILE *const fp = fopen("test/sample.txt", "r");

    TEST_ASSERT(fp);

    while (fgets(buf, sizeof buf, fp)) {
        buf[strcspn(buf, "\n")] = '\0';
        TEST_ASSERT((lines[line_count] = strdup(buf)));
        ++line_count;
    }
    
    rewind(fp);

    FileBuf fbuf = {};

    TEST_CHECK(FUNCTION_UNDER_TEST(fp, &fbuf));
    TEST_CHECK(fbuf.count == 555);
    TEST_CHECK(fbuf.size == 120635);

    for (size_t i = 0; i < fbuf.count; ++i) {
        TEST_CHECK((strcmp(lines[i], fbuf.lines[i].line) == 0));
    }

    fclose(fp);
}

TEST_ARRAY_TYPE Test_Array_Name[] = {
    { TEST_ARRAY_MAPPING(FUNCTION_UNDER_TEST) },
    { nullptr, nullptr },
};

Я закомментировал заголовки и протестировал файл readlines_fread.c в текущем каталоге, который содержит только:

Contents of readlines_fread.c

makefile выглядит так:

FUNCTION_UNDER_TEST = readlines_fread
INCLUDE_FILE_NAME = "$(FUNCTION_UNDER_TEST).c"

CFLAGS = -E -DINCLUDE_FILE_NAME='$(INCLUDE_FILE_NAME)' -DFUNCTION_UNDER_TEST=$(FUNCTION_UNDER_TEST)

PROG = test97

all: $(PROG).o

Предварительно обработанный результат выглядит следующим образом:

# 1 "test97.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 418 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "test97.c" 2
# 17 "test97.c"
# 1 "./readlines_fread.c" 1
Content of file readlines_fread.c
# 18 "test97.c" 2
# 27 "test97.c"
void test_readlines_fread_success(void)
{

    char buf[1024];
    char *lines[1024];
    size_t line_count = 0;
    FILE *const fp = fopen("test/sample.txt", "r");

    TEST_ASSERT(fp);

    while (fgets(buf, sizeof buf, fp)) {
        buf[strcspn(buf, "\n")] = '\0';
        TEST_ASSERT((lines[line_count] = strdup(buf)));
        ++line_count;
    }

    rewind(fp);

    FileBuf fbuf = {};

    TEST_CHECK(readlines_fread(fp, &fbuf));
    TEST_CHECK(fbuf.count == 555);
    TEST_CHECK(fbuf.size == 120635);

    for (size_t i = 0; i < fbuf.count; ++i) {
        TEST_CHECK((strcmp(lines[i], fbuf.lines[i].line) == 0));
    }

    fclose(fp);
}

TEST_ARRAY_TYPE Test_Array_Name[] = {
    { "test_readlines_fread_success", test_readlines_fread_success },
    { nullptr, nullptr },
};

Я считаю, что это очень близко к тому, чего вы хотели достичь. Запустив make FUNCTION_UNDER_TEST=readlines_getline, вы можете переключиться на другой исходный файл и имя функции.

Очевидно, что вы можете определить, откуда следует включать файлы, с помощью такой опции, как -I../src, предоставленной в качестве одного из CFLAGS.

GNU Make копирует вывод в test97.o, потому что он добавляет -c и -o test97.o в командную строку компилятора:

cc -E -DINCLUDE_FILE_NAME='"readlines_fread.c"' -DFUNCTION_UNDER_TEST=readlines_fread   -c -o test97.o test97.c

Другие варианты make могут иметь другие правила.

gcc -E -DINCLUDE_FILE_NAME='"readlines_fread.c"' -DFUNCTION_UNDER_TEST=readlines_fread -c test97.c

См. также Каковы преимущества относительного пути, например «../include/header.h», для заголовка?

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

Обозначение #include, показанное в ответе wizzwizz4 (версия 1), не будет работать. Конкатенация строк происходит на этапе 6 (см. C11 §5.1.1.2 Фазы перевода ), а предварительная обработка происходит на этапе 4. Вы можете использовать имя макроса в #include MACRO_NAME, но MACRO_NAME должно расширяться до "file.name" или <file.name> практически напрямую. См. также §6.10.2 Включение исходного файла ¶4 и особенно сноску 170.

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

Например:

#define HEADER_NAME(base) <base.h>

#include HEADER_NAME(somename)

При правильных параметрах -I (-I. для случая, когда somename.h находится в текущем каталоге), это будет включать somename.h для вас. Конечно, вы можете адаптировать это, чтобы включить исходный файл в другой каталог, но вам все равно придется включить соответствующие параметры -I в командную строку:

#define SOURCE_FILE(base) <../src/base.c>

#include SOURCE_FILE(testfile)

Или (с более правдоподобным набором RELATIVE_PATH в командной строке):

#define RELATIVE_PATH ../src
#define HEADER_NAME(base) <RELATIVE_PATH/base.h>

#include HEADER_NAME(somename)

Во всяком случае, это работает с GCC (он же Clang) на macOS.

То, что вам нужно использовать, также зависит от того, где вы выполняете компиляцию. Обратите внимание, что спецификация POSIX для c99 компилятор включает спецификацию того, как #include <name.h> и #include "name.h" взаимодействуют с -Isome/path/name:

-I directory

Измените алгоритм поиска заголовков, имена которых не являются абсолютными путями, чтобы искать в каталоге, указанном в пути к каталогу, прежде чем искать в обычных местах. Таким образом, заголовки, имена которых заключены в двойные кавычки (""), будут искаться сначала в каталоге файла со строкой #include, затем в каталогах, указанных в опциях -I, и в последнюю очередь в обычных местах. Для заголовков, имена которых заключены в угловые скобки ("<>"), поиск заголовка осуществляется только в каталогах, указанных в опциях -I, и то в обычных местах. Поиск в каталогах, указанных в опциях -I, осуществляется в указанном порядке. Если опция -I используется для указания каталога, который является одним из обычных мест поиска по умолчанию, результаты не указаны. Реализации должны поддерживать не менее десяти экземпляров этой опции при одном вызове команды c99.

Обратите особое внимание на фрагмент правила:

… следует искать сначала в каталоге файла со строкой #include …

В комментарии вы спрашиваете:

А если файлы отмечены "cread/src/FileBuf.h", что мне нужно?

Тогда в каталоге cread/test вам понадобится -I../... Или, если проект находится в /home/username/project/cread (с подкаталогами test и src), вы можете использовать -I$HOME/project (в нотации оболочки; -I$(HOME)/project или -I${HOME}/project в нотации make — и нотация -I${HOME}/project будет работать и в make-файле).

По сути, препроцессор будет брать имя из директивы #include (например, cread/src/fileBuf.h и добавлять элементы из списка опций -I для создания имени файла.

Итак, используя -I../.., вы получите ../../cread/src/fileBuf.h, который должен быть путем к файлу относительно подкаталога test. Или с -I${HOME}/project у вас будет /home/username/project/cread/src/fileBuf.h.