Есть тестовая консольная прога типа:

bool test_1() {…}
bool test_2() {…}
bool test_3() {…}
bool test_4() {…}

void main()
{
   test_1();
   test_2();
   test_3();
   test_4(); 
}

Хочу в main ничего не писать. То есть при написании test_5 чтоб ее запуск автоматически добавлялся в main
Как лучше такое провернуть?

фокус покус

#include <stdlib.h>

struct Init
{
   Init() { printf("main!\n"); }
}

Init init;

int main() {}

выхлоп

main!

Здравствуйте, Великий Мессия, Вы писали:

И? Писать каждый раз новый класс и делать глобальную переменную этого класса? Ну так добавление глобальной переменной — это все равно что строка в main. Суть не в том, чтоб в main не писать, а в том, чтоб не писать ничего нигде кроме самой новой тестовой функции

я показал логику которой пользуют аля гуглтест

а класс не обязательно писать
если мета программирование
в конце концов есть еще макросы

а если это голый С то тоже можно в спец секцию внести
которая будет вызываться до main

Здравствуйте, Великий Мессия, Вы писали:

А если мне не надо до main? То есть в начале main какая-то инициализация ядра, потом сами тесты ядра, потом освобождение ядра.

почему бы для начала не изучить как это сделано в существующих тест системах, а не изобретать велосипед?
к примеру в
https://github.com/catchorg/Catch2.git
https://github.com/google/googletest.git

если не надо до main
то изучить как сделано выше
или догадаться строить свою систему подписок и выполнения событий окученных макросами = что бы получить то что уже сделано до вас

Здравствуйте, Hоmunculus, Вы писали:

H>Как лучше такое провернуть?

gtest

Здравствуйте, Hоmunculus, Вы писали:

H>И? Писать каждый раз новый класс и делать глобальную переменную этого класса? Ну так добавление глобальной переменной — это все равно что строка в main. Суть не в том, чтоб в main не писать, а в том, чтоб не писать ничего нигде кроме самой новой тестовой функции

Гугл тест тебе в руки. Там регистрация тестов в макросах завёрнута. Ну или сам можешь сделать, принцип тебе показали

Здравствуйте, Hоmunculus, Вы писали:

H>Хочу в main ничего не писать. То есть при написании test_5 чтоб ее запуск автоматически добавлялся в main
H>Как лучше такое провернуть?

Автоматическое добавление плохо, т.к. это становится внедрением зависимостей (DI) без определённых соглашений.
Иногда нужно запустить часть тестов или один тест, т.е. движок тестов должен это переваривать.
Тесты могут быть запущены в специфической конфигурации или среде, т.е. стандартные движки могут не справиться.

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

Здравствуйте, Hоmunculus, Вы писали:

H>Есть тестовая консольная прога типа:
H>

H>bool test_1() {…}
H>bool test_2() {…}
H>bool test_3() {…}
H>bool test_4() {…}

H>void main()
H>{
H>   test_1();
H>   test_2();
H>   test_3();
H>   test_4(); 
H>}
H>

Когда-то я делал свою библиотеку юнит тестов где решал такую штуку, подготовил даже большое описание: https://habr.com/ru/articles/434906/

Принцип был примерно такой:

// Объявляете:
template <int N> static void Test() { throw TheCaseIsAStub(); }

// Специализации
template<> void Test<1>() {..}
template<> void Test<2>() {..}
template<> void Test<3>() {..}

// Запускатор
template<int N> void Run() 
{
   if (N < 0)
      return; 

   try { 
      Test<N>();
   }
   catch (TheCaseIsAStub )
   {
   }

   Run<N-1>();
}

void main()
{
   Run<100>();
}

Здравствуйте, Hоmunculus, Вы писали:

H>Хочу в main ничего не писать. То есть при написании test_5 чтоб ее запуск автоматически добавлялся в main
H>Как лучше такое провернуть?

Открыть свой исполняемый файл и поискать там символы test_XXX.

Но. Умный линкер может их и повыкидывать.

Здравствуйте, F3V, Вы писали:

F3V>Автоматическое добавление плохо

Только если оно неуправляемое.

Я вот хотел бы иметь возможность явно указывать, что в начале и/или конце метода следует автоматически вставлять вызов определенной функции (например, метода Check). Или по умолчанию вставлять во все методы, кроме тех, которые явно исключены из этого. На самый худой конец — получать от компилятора предупреждение, если в каком-то методе Check не вызывается, и предупреждение не подавлено явно.

Но кто ж в комитете на такое пойдет? Несмотря на то, что подобные, простые в реализации, вещи способны радикально повысить надежность программы, против них придумают 100500 возражений о том, что они "нарушают идею/связность/прозрачность/чистоту языка". При том, что и от идеи, и от связности, и от прозрачности, и от чистоты уже давно остались только воспоминания.

F3V>это становится внедрением зависимостей (DI) без определённых соглашений.

Именно поэтому соглашения и должны объявляться явно, чтоб их можно было легко найти.