Help with software architecture?

Question

C++ / C#

Friends, I need advice in designing software architecture, so that later it would not be excruciatingly painful.
A program that manages a stand for testing some pieces of iron.
The subsystems are planned as follows:

1. Label printing
   
2. Stand control via ModBus
   
3. Request a serial number from the server
   
4. Sending a report to the server
   
5. Exception Logging
   
6. Test progress logging
   
7. Graphic display of test progress
   
8. The test itself
   

For the convenience of work, I think to use the "Facade" pattern, I don't know if it will fit in or not.
The most important part is the hardware test, which can consist of many subtests. I'm thinking of making an interface like ITest:

interface ITest
{
    void Run();
    Result Result();
}

And implement it in subtest classes.
There are many devices, for this or that device you need to use different subtests. At what you need to enable / disable subtests without changing the code. I think it can describe the interface:

interface IDeviceForTest
{
   bool SelfTest {get; set;}
   bool PowerTest {get; set;}
   ...
   void Test();
}

Then implement the interface

class Device1 : IDeviceForTest
{
    public bool SelfTest {get; set;} = true;
    public bool PowerTest {get; set;} = true;
    public void Test() 
   {
       if (SelfTest)
       {
            var selftest = new SelfTest();
            selftest.Run();
       }
...
   }
}

Serialize device objects to json and restore the object with possible edits (on/off) of the subtest json file during startup.
In general, it's clumsy. And it's not very clear how best to get the test result, so that the logic for processing the result is not done in the device class. Testing of the entire device must be stopped if any subtest fails. What do you advise?

Answer 1

If I understood the task correctly, then:
1) We create the ITestDevice interface , which will be the same for all pieces of iron.
2) Each piece of hardware has its own adapter that implements ITestDevice . It takes into account the features of each piece of iron, and is adjusted to a single interface.
3) Each device must have its own unique Id (GUID/int32/string). This Id is initialized in the adapter, or in the device class that is used in the adapter.
4) The ITest interface is created . It is the same for all tests.
5) We create tests.
6) We hammer in pairs Id_testDevice - Id_test in the data warehouse.
7) We launch the application, it reads data from the storage, and transfers to eachITestDevice its lists of tests, then runs them.
ITestDevice - has a list of tests (ITest) that it runs.
ITest - can be either an atomic test (1 pc) or a composite one (inside it contains a list of other tests, without fanaticism and recursions)).
If there are tests only for specific devices, then types can be assigned to the tests, and they can be checked (by the hierarchy or by the type field).
A) If the test fails, the device ends the run. This is done by the device itself, which looks at the return value of each test, looping through them. The test can have a Boolean Success property.
B) Or you can make a TestManager that receives an ITestDevice and its ITest list, and one by one in the loop, it starts feeding tests to the device (for example, to the ITestDevice.Run(ITest test) method), checking the result, writing it to the log and deciding whether to continue testing or go to the next device. This approach will separate the rules for passing the test suite from the device itself, the manager can get them from the repository.