Нужно покрыть тестами некоторый функционал, который завязан на нескольких статических классах. Если конкретно, то статические классы из Azure SDK и относятся к Azure Storage Table.
Есть ли какие-то вменяемые способы изолировать свой код от статических классов чтоб написать юниттесты? Сейчас написали тесты с использованием Microsoft Fakes, но эта фича доступна только в Enterprise версии Visual Studio, а руководство пересаживает нас на Visual Studio Professional, в которой этих самых Fakes нет.
Я попробовал ввести дополнительный слой абстракции чтоб изолировать статические классы и вызывать их косвенно, через свою собственную обёртку. Но результат мне не понравился. В классах вроде CloudTable или TableOperation куча методов и писать обёртку под каждый из методов — мартышкин труд.
Есть ли какой-то более правильный подход к таким юниттестам?
С уважением, Artem Korneev.
Re: Юниттесты для статических классов - что, если не fakes?
Здравствуйте, Artem Korneev, Вы писали:
AK>В классах вроде CloudTable или TableOperation куча методов и писать обёртку под каждый из методов — мартышкин труд. AK>Есть ли какой-то более правильный подход к таким юниттестам?
Так не надо делать моки 1:1, надо опираться на юз-кейсы. Тогда выяснится, что для каждого юз-кейса хватит частичных врапперов (остальное пусть смело кидает NotImplemented, как это и генерится Студией в ответ на "реализовать интерфейс"). Ну и да, на каждый юз-кейс может быть свой вариант враппера одного и того же статического класса.
Если всё вышесказанное мимо — покажите пример кода, с чем боретесь.
Re[2]: Юниттесты для статических классов - что, если не fakes?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Так не надо делать моки 1:1, надо опираться на юз-кейсы. Тогда выяснится, что для каждого юз-кейса хватит частичных врапперов (остальное пусть смело кидает NotImplemented, как это и генерится Студией в ответ на "реализовать интерфейс"). Ну и да, на каждый юз-кейс может быть свой вариант враппера одного и того же статического класса.
Так ведь кинуть NotImplemented — примерно столько же писанины, что и вызвать нужную реализацию из целевого класса.
Для примера — статический класс CloudTable. Можно, конечно, написать врапперы для десятка методов, которые сейчас используются. Но наши библиотеки будут потом использоваться несколькими командами, меня закидают помидорами, если я выдам куцую версию такого функционала.
С уважением, Artem Korneev.
Re[3]: Юниттесты для статических классов - что, если не fakes?
Здравствуйте, Sinix, Вы писали:
S>А не проще такие штуки в integration tests перенести?
Integration tests для этой части уже есть.
Тут другое. Менеджеры хотят "80%+ code coverage", приходится заниматься ерундой, писать тесты просто "чтоб было".
Я пока написал через Microsoft Fakes, но не хочется связываться с fakes — сложно, громоздко и требует VS Enterprise. Вот подумываю, как бы от этого дела избавиться.
S>Один фиг вы рано или поздно Azure Storage Emulator будете подрубать для тестов.
Уже. В функциональных тестах.
В юниттестах стоят костыли чтоб получить нужный test coverage.
