Очистить частные переменные stati c между юнит-тестами - PullRequest
Новая
       8

Очистить частные переменные stati c между юнит-тестами

0 голосов
/ 04 марта 2020

У меня есть класс, который выглядит примерно так: 

public class DiscoveryDocumentCache
{
    static DiscoveryDocumentCache()
    {
        cache = new MemoryCache(discoveryDocumentCacheName);
    }

    private static MemoryCache cache;

    // Other stuff...
}

Я хочу, чтобы кэш памяти имел статус c, чтобы он был общим для всех экземпляров класса.

Это отлично работает для реальных случаев использования. Я борюсь с моими юнит-тестами. Поскольку переменная cache является stati c, она накапливает все различные значения, которые в нее помещаются.

В моем сценарии использования отсутствует опция «удалить». (Они просто истекают из кеша.)

Я добавил это в мой DiscoveryDocumentCache класс: 

    public void __UnitTesting__CleanUpMemoryCacheBetweenTests()
    {
        cache.Dispose();
        cache = new MemoryCache(discoveryDocumentCacheName);
    }

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

. NET Framework имел несколько способов доступа к закрытым переменным класса, если вы действительно думали, что должны. Есть ли что-то подобное, что я могу сделать, чтобы сбросить эту переменную stati c в моем методе TearDown unit-test?

1 Ответ

0 голосов
/ 04 марта 2020

Не уверен, что вы подумали, что это ответ или просто длинный комментарий. : -)

Ваши тесты работают хорошо, потому что они вам что-то говорят. Они говорят: «Это неправильное использование статического c экземпляра».

Статика всегда подозрительна, хотя и не всегда плоха. Плохо то, что вы используете stati c для реализации шаблона синглтона таким образом, что впоследствии вы не можете его контролировать. То есть, ваши индивидуальные экземпляры сами решают, какой кеш (синглтон) использовать, а не говорят, что использовать.

Как подсказывает @Vaccano, вам лучше использовать какое-то внедрение зависимости. Переведите это на «Скажите каждому объекту, какой кеш использовать, вместо того, чтобы он сам разбирался в этом». Это одна из тех вещей, которые требуют небольших предварительных вложений, чтобы избежать проблем в будущем.

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

...