Здравствуйте, Svjat, Вы писали:
То есть ты хочешь сказать, что любой класс можно привести к виду твоего примера?
Допустим те хреновины, что хранятся в HrenovinaStorage, не только там хранятся, но еще и как то
обрабатываются. Ну типа, если item уже находится в хранилище 5 суток, то у него надо изменит один
из филдов, ну допустим молоко прокисло, выставляем флаг на удаление. При этом есть набор правил для
разных видов продуктов. Допусти мука 3 года там может валятся. У нас появляются как минимум список правил
и менеджер, который чистит хранилище по этим правилам. Причем этот менеджер получает этот список из какого-
либо outside ресурса, файла к примеру. Само-собой эти члены должны быть приватными, кому какое дело по каким
правилам производится хранение, главное что бы со склада можно было что то взять или положить туда.
Что бы оттестировать алгоритм проверки срока хранения молока, ты положишь продукт в хранилище и через какое то время проверишь, есть он или нет. Валидно. А правильность инициализирования списка правил ты так же косвенно будешь тестировать? Допустим этот алгоритм достаточно сложен, вовлекает в процесс набор полей класса, инициализит их определенным образом. Я согласен что в случае возникновения деффекта твой тест с молоком не отработает. Но сколько тебе потребуется времени на обнаружение этого дефекта?
Другой вопрос что в этом случае надо задуматься о рефакторинге и попробовать вытащить алгоритм в отдельный
интерфейс. Тогда возможно удастся обойти закрытые члены, но в любом случае полностью от этого у меня пока отказаться не поучается. Возможно это прийдет с опытом, не знаю, посмотрим.
S>давай на примерах, вот мой:
S>в САД есть класс — HrenovinaStorage
S>его Responsibilities — постоянное хранение объектов типа Hrenovina,
S>средства добавления / удаления / получения объекта по ключу
S>соотв. у него есть след. методы
S>S>public void Start();
S>public void Stop();
S>public void Add( Hrenovina hrn );
S>public void Remove( string key );
S>public void Clear();
S>public Hrenovina Get( string key );
S>
S>теперь пишем простой тест:
S>
S> HrenovinaStorage storage = new HrenovinaStorage( TmpName );
S> storage.Start();
S> storage.Clear(); // сразу все чистим
S> storage.Add( new Hrenovina( key ) ); // добавляем новый объект
S> storage.Get( key ); // проверяем добавил или нет
S> storage.Remove( key ); // ...
S> storage.Get( key ); // ...
S> // теперь проверяем как он перманентно хранит объекты
S> storage.Add( new Hrenovina( key2 ) );
S> storage.Add( new Hrenovina( key3 ) );
S> storage.Stop();
S> storage = null;
S> HrenovinaStorage storage = new HrenovinaStorage( TmpName );
S> storage.Start();
S> storage.Get( key2 ); // проверяем сохранил или нет
S> storage.Get( key3 );
S> // -------------------
S>
S>все, если тесты срабатывают, значит класс делает то, что должен
S>теперь покажи где здесь место для проверки приватных методов и полей? ( а они таки есть ).