Половина методов имеет реализацию, а половина нет. При этом, часть приватных полей должна быть заполнена потомками, перед вызовом методов базового класса.

Как это вообще тестировать ?

Спиридончикчасть приватных полей

защищенных (protected) имелось ввиду.

Я 100% поддерживаю версию, что абстрактные классы могут содержать логику.
И даже более чем могу себе представить, что предок переопределит всего какие-нибудь 10% методов и класс будет полностью функционален-т.е. все будет делать абстрактный родитель. Почему бы и нет.

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

Вот думаю как быть с тестированием класса, который "фифти-фифти" и сам имеет методы с логикой, и абстрактные методы, к которым обращается, в расчете, что они перегружены потомками.

Так у меня уточняющий вопрос.
У меня есть абстрактный класс. А еще есть 2 его потомка (для того абстрактные классы и существуют, чтобы дать возможность "разветвиться" коду).

Вы как предлагаете тестирова ? Создать еще одного потомка, но абстрактные методы должны возвращать некие константы - чтобы я мог расчитать логику в абстрактном классе, и сравнить ее в асерте ?

правильно понял я ?

skoleИспользование абстрактного класса в качестве base class это такая же бессмыслица (1) , как и его тестирование (2) , как раз в этом случае нужно использовать обычный nested class или интерфейс, последний в целях использования не экземпляра класса, а его типа.

Абстрактный класс предполагает, прежде всего, определение набора методов для нижележащих классов и (override) методов (3) , да, он может задавать поведение - return int, например, но практическая реализация метода находится всегда за кулисами. Именно для этого и применяются абстрактные классы – отделить другой логический блок от общего функционала, по другому это называется best practice.

Продолжайте дискуссию, товарищи


(1) А чем еще должны быть абстрактные классы, как не base ? Если мне нужно определить только контракт, без логики, я использую интерфейс. Если же мне нужно заложить какую-то логику, то это абстрактный класс.
Хотя такая классификация не совсем полна. Сейчас не вспомню, но где-то прочитал умную мысль: Интерфейс означает "ведет себя как", а абстрактный класс означает "является".

Интерфейс можно вставить во многие совершенно никак не связанные между собой классы. Как например IEnumerable, IEquatable. Очень многие классы могут быть Перечисленны и Сравнены между собой. Но все эти классы вообще никак не связанны (разные классы, в смысле) между собой.

Принадлежность к базовому классу более тесная связь. Гляньте, к примеру, на класс System.data.common.dbconnection. Все его потомки физически тесно связаны между собой, тем, что основаны на фундаменте одного базового класса.

Этот класс явно требует от потомков переопределить часть методов:
Примечания для наследующих объектов
При наследовании из объекта DbConnection необходимо переопределить следующие члены: Close, BeginDbTransaction, ChangeDatabase, CreateDbCommand, Open и StateChange. Необходимо предоставить следующие свойства: ConnectionString, Database, DataSource, ServerVersion и State.

Если не переопределелите, то словите NotImplementedException во время выполнения.

(2). Если есть код, который выполняет некую логику, то она должна быть протестирована.
Пусть не 100% покрытия кода, но существенная часть критичных вычислений - точно. Это аксиома юнит тестов. Почему абстрактный класс должен отходить от этой аксиомы ?

(3) Это описание больше подходит интерфейсу. Это интерфейс всего лишь описывает контракт методов, без реализации.
Гляньте на иерархию наследования dbconnection. Все его предки, как и он сам, наверняка напичканы логикой. Что же, их не нужны юнит тесты ?

skoleДля того чтобы определить функционал в base class совсем не обязательно объявлять его абстрактным (1).

Абстрактный класс почти всегда является «фасадом», топ-классом, если понятней, все остальные классы, которые его наследуют, инкапсулируют логику и функционал методов в своей реализации(2), как в случае с той либой, для каждого соединения мы используем свою процедуру, но для их использования нам нужно вызвать публичные(3) методы абстрактного класса.

Интерфейсов подробно касаться не буду, это отдельная тема, интерфейс, прежде всего, инкапсулирует в себе тип класса(4), что позволяет избежать межклассовой зависимости в логике.

А тесты пишутся на конкретный элемент логики, а не на абстрактный (5).

(1) А кто говорит иное ?
Никто не решает, что "я вот хочу создать абстрактный класс". Направление мыслей скорее обратное "Данный метод в данном классе не имеет смысла. Методы должны определить наследники. Выходит мы получили абстрактный класс. Ок"

Слово абстрактный, просто напоминание для програмимста, что "ты не сможешь создать объект".
Я уже не помню, но кажется в C++ вообще нет понятие "абстрактный" в ключевых словах (по крайней мере то, каким я его помню годах в 90ых). Там абстрактным считался класс, у которого были "чистые виртуальные функции. =0".
А интерфейсом считался класс, у которого все функции были чистыми-виртуальными, между прочим.

Эти термины были всего лишь договоренностью между программистами.
Введение слов Abstract и Interface просто задокументировало факт различий между этими разными сущеностями.
Прогресс не стоит на месте, языки программирования развиваются. Что-то появляется сначало ввиде формальных договоренностей между программистами. И если это приживается, то переходит в спецификацию языка.

Абстрактный класс - это просто класс. И как просто класс, он может содержать какую угодно логику. И то, что он "ой. получился абстрактным" не делает его ни лучше, ни хуже других.

Есть еще такое понятие, как "исключение дублирования кода". Базовые классы занимаются этим самым исключением, реализуя в себе максимум логики.

(2) Собственно вы описали совершенно типичный базовый класс. Простой базовый класс, создающий некоторые очертания и границы функционала, за который не могут выйти его наследники.

Точнее может и могут. От DbConnection вы без проблем можете породить наследника занимающийся форматированием текста. Но такой подход в архитектуре просто вас же и запутает.

И я пожелаю удачи тому, программисту которому достанется сопровождать проект, в котором наследник DbConnection занимается форматированием текста, а парсер XML соединением с базой данным и поддержкой транзакционности :)


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

(4) Чито ? как интерфейс может инкапсулировать в себе тип ?
Какой тип инкапсулирует в себе интерфейс IEnumerable ?

Интерфейс инкапсулирует в себе поведение. Класс, реализующий интерфейс говорит, что он обязуется вести себя так как указанно.

Это, в частности, поможет "избежать межклассовой зависимости в логике" (inversion of control), но и не только. Это не единственная функция интерфейсов.

(5) Класс называется абстрактным, всего лишь потому, что у него есть абстрактные методы.
Но у него есть и обычные методы. Вот их и надо тестировать.