Как выполнить модульное тестирование реализаций интерфейса с минимальным дублированием - PullRequest
0 голосов
/ 29 апреля 2019

У меня есть решение Xamarin в VS2017, которое несколько раз реализует физическое устройство (через usb / serial и bluetooth) в Windows UWP и Android.Все эти устройства реализуют IMyDevice, который определяет простой конечный автомат, который моделирует MyDevice, подключенный или нет, и измеряющий или нет.

Я тестирую эти реализации, используя Xunit, в соответствующих им пространствах имен, и, поскольку все они реализуют IMyDevice, я получаю довольно много тестов, которые буквально идентичны и в настоящее время повторяются 3 раза.Вскоре я добавлю больше устройств и должен найти способ не допустить, чтобы это повторение полностью вышло из-под контроля.

Для тестирования моделей представлений я собираю сборку в отдельном общем пространстве имен и включаю ее в свойразличные проекты модульных тестов, использующие:

AddTestAssembly(typeof(MyViewModel).GetTypeInfo().Assembly);

Это работает для моделей представлений, потому что мне не нужны какие-либо типы платформ, но, увы, я не думаю, что смогу пройти реализацию MyDeviceв сборку, которая уже построена!

Более целесообразным было бы использование службы зависимостей Xamarin

DependencyService.Get<MyDevice>();

Однако, мне кажется, что концептуально неправильно, что мои модульные тесты Serial / Bluetooth должнытребуют формы Xamarin.И я не уверен, что все равно будет сделано, потому что мне все еще нужно избавиться от неоднозначности моего серийного устройства и устройства Bluetooth в Windows.

Поэтому я выписал это длинным шрифтом.Я использовал Xuint в двух проектах / пространствах имен, таких как:

namespace Test.MyApp.UWP {
    public class TestMyBluetoothDeviceUWP {
        [Fact]
        void DeviceDoesntSuck() {
            Assert.False(new MyUWPBluetoothDevice().sucks());
        }
    }
    public class TestMySerialDeviceUWP {
        [Fact]
        void DeviceDoesntSuck() {
            Assert.False(new MyUWPSerialDevice().sucks());
        }
    }
}

namespace Test.MyApp.Droid{
    public class TestMyDeviceDroid {
        [Fact]
        void DeviceDoesntSuck() {
            Assert.False(new MyDeviceDroid().sucks());
        }
    }
}

Популярный ответ на вопросы, подобные моим, кажется, использует [Теория]

namespace Test.MyApp{
    public class TestMyDevice {
        [Theory]
        [ClassData new MyUWPBluetoothDevice()]
        [ClassData new MyUWPSerialDevice()]
        [ClassData new MyDeviceDroid()]
        void DeviceDoesntSuck(IMyDevice myDevice) {
            Assert.False(myDevice.sucks());
        }
    }
}

, это помогает с определенными устройствамивнутри одного и того же пространства имен, однако это не помогает с повторением в тестовых проектах (пространствах имен)

. На сегодняшний день лучшее решение, которое я могу придумать (что не так уж хорошо), - это определить тесты статически и обернутьих в вызывающих программах в тестовых проектах

namespace Test.MyApp{
    public static class TestMyDevice {
        static void DeviceDoesntSuck(IMyDevice myDevice) {
            Assert.False(myDevice.sucks());
        }
    }
}

namespace Test.MyApp.UWP {
    public class TestMyDeviceUWP {
        [Theory]
        [ClassData new MyUWPBluetoothDevice()]
        [ClassData new MyUWPSerialDevice()]
        void DeviceDoesntSuck(IMyDevice myDevice) {
            Test.MyApp.TestMyDevice.DeviceDoesntSuck(myDevice);
        }
    }
}

namespace Test.MyApp.Droid{
    public class TestMyDeviceDroid {
        [Fact]
        void DeviceDoesntSuck() {
            Test.MyApp.TestMyDevice.DeviceDoesntSuck(new MyDeviceDroid());
        }
    }
}

это более легко обслуживаемо, поскольку у меня есть только одна реализация каждого теста, но все еще много дублирования, поскольку мне нужно обернуть каждую из них на каждой платформе

Таким образом, если кто-нибудь знает, как: выполнить целый ряд тестов для различных реализаций интерфейса, зависящих от времени выполнения, которые живут в разных проектах / пространствах имен, мне было бы очень интересно услышать, что вы скажете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...