Помощь в архитектуре ПО?

Question

[Дмитрий]

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

1. Печать этикеток
   
2. Управление стендом по ModBus
   
3. Запрос серийного номера с сервера
   
4. Отправка отчета на сервер
   
5. Логирование исключительных ситуаций
   
6. Логирование хода теста
   
7. Графическое отображение хода теста
   
8. Сам тест
   

Для удобства работы думаю использовать паттерн "Фасад", не знаю впишется или нет.
Самая важная часть это тест оборудования, который может состоять из многих подтестов. Думаю сделать интерфейс типа ITest:

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

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

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

Потом реализовать интерфейс

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();
       }
...
   }
}

Сериализовать объекты устройств в json и во время запуска восстанавливать объект с возможными правками (вкл/откл) json-файла подтеста.
В общем неуклюже И не очень понятно, как лучше получать результат теста, чтобы логику обработки результата не делать в классе устройства. Тестирование всего устройства нужно останавливать, если какой-то подтест не пройден. Что посоветуете?

Comments

[Дмитрий]

Пока мысль такая:

1. создать набор тестов (классы тестов)
   
2. в текстовых файликах указать список id тестов для конкретных моделей
   
3. после запуска теста с помощью фабрики создать объекты тестов по их id и запустить их
   

Проблема остается в другом, что, например, PowerTest тоже может иметь поддесты, которые для каждого устройства могут выполняться не все. Создавать кучу отдельных тестов типа PowerTest1, PowerTest2 кажется не очень разумным. Тогда тестов (классов теста) таких будет миллион.

Answer 1

[MrDywar Pichugin]

Если правильно понял задачу, то:
1) Создаем интерфейс ITestDevice, который будет единым для всех железок.
2) Для каждой железки создается свой адаптер, который реализует ITestDevice. В нем учитываются особенности каждой железки, и подгоняются под единый интерфейс.
3) Каждый девайс должен иметь свой уникальный Id (GUID/int32/string). Инициализируется этот Id в адаптере, или в классе устройства, который используется в адаптере.

4) Создается интерфейс ITest. Он единый для всех тестов.
5) Создаем тесты.

6) Забиваем пары Id_testDevice - Id_test в храналище данных.
7) Запускаем приложение, оно читает данные из хранилища, и передает каждому ITestDevice свои списки тестов, затем запускает их.

ITestDevice - имеет список тестов (ITest) которые он запускает.
ITest - может быть как атомарным тестом (1 шт), так и композитным (внутри себя содержит список других тестов, без фанатизма и рекурсий)).
Если есть тесты только для конкретных девайсов, то тестам можно прописать типы, и проверять их (иерархией или полем type).

А) Если тест не пройдет, то девайс завершает прогон. Это делает сам дейвайс, который смотрит на возвращаемое значение каждого теста, перебирая их в цикле. У теста может быть булево свойство Success.
Б) Или можно сделать TestManager, который получает ITestDevice и его список ITest, и по одной штуке в цикле начинает скармливать тесты девайсу (например в метод ITestDevice.Run(ITest test)), проверяя результат, записывая в лог и решать продолжить тестирование или перейти к следующему дейвасу. Такой подход отделит правила прохода набора тестов от самого девайса, менеджер может получать их из хранилища.

Comments

[Дмитрий]

Спасибо! Примерно тоже самое сделал. Но есть еще другие проблемы, что один и тот же тест может быть запущен сотни раз для построения графика разброса параметров и пр. грабли))

[Дмитрий]

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

[MrDywar Pichugin]

Дмитрий, В тесте может быть счетчик Count (сколько раз его нужно запустить), и Interval (сколько ждать перед запуском следующего теста, или перед началом текущего). Собирать суммарный Result может композитный тест, и возвращать его после запуска всех своих вложенных тестов.

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

Быстрая правка - это уже не про C#, да. Тут PowerShell может подойти, в нем можно использовать C# код, и лего менять его. Пример - https://trevorsullivan.net/2014/10/25/implementing...

Но возможно проще будет другой язык использовать, чем играться с powershell + C#.