Тестирование пути обновления для сохраненных настроек

Question

Я работаю в C #, и у меня в программном обеспечении есть собственный объект «настройки», который сохраняется на диске и который я должен иметь возможность тестировать при обновлении версий своего программного обеспечения.

Например, если у меня есть программное обеспечение с «версией A» и у меня есть настройки из этой версии, при обновлении до «версии B» моего программного обеспечения я хочу убедиться, что «настройки A» могут быть обновлены без ошибок.

Когда позже я обновляюсь до «версии C» моего программного обеспечения, я должен проверить пути обновления с A-> C, а также B-> C (версия n + 1 требует на n + 1 больше тестовых случаев, чем версия n сделал).

Большая проблема, с которой я столкнулся, заключается в том, что этот экспоненциальный рост путей тестирования будет быстро усложнен.

Есть ли стандартный способ борьбы с этим?

---

Вот некоторые важные проблемы, с которыми я столкнулся:

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

MSDN говорит, что они создаются так, как настройки ClickOnce, не поддерживают это напрямую, и я должен «разработать [свои] собственные классы пользовательских настроек для хранения настроек на удаленном компьютере».

Answer 1

Я добавил комментарий о возможном выполнении этого при первом запуске приложения после обновления.

Мне не ясно, волнует ли вас необходимость разработки всех этих путей обновления или получения этого интегрированногов вашу процедуру установки / обновления.

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

public interface ISettingsUpgrader
{
    void UpgradeSettings();
}

public abstract class SettingsUpgrader : SettingsUpgrader
{
    protected int version;

    public virtual void UpgradeSettings()
    {
        // load settings and read version info
        version = settingsVersion;
    }
}

public class SettingsUpgraderV2 : SettingsUpgrader
{
    public override void UpgradeSettings()
    {
        base.UpgradeSettings();
        if(version > 1) return;

        // do the v1 -> v2 upgrade
    }
}

public class SettingsUpgraderV3 : SettingsUpgraderV2
{
    public override void UpgradeSettings()
    {
        base.UpgradeSettings();
        if(version > 2) return;

        // do the v2 -> v3 upgrade
    }
}

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

Для тестирования каждая новая версия требует только проверки (1), что базовый метод вызывается -- функциональность которого уже охватывается существующими тестами, и (2) что последний v (n-1) -> v (n) правильно выполнен.

В качестве дополнительного примечания, это, вероятно, хорошоФорма для реализации процедуры отката настроек на каждом уровне, если только вы не запретили откат к предыдущей версии.

Answer 2

Установщики обычно должны запускаться с правами администратора и, следовательно, обычно имеют доступ к сети.Все, что вам нужно сделать, это получить доступ к конфигурации приложения текущей версии (или к ключу реестра, если вы сделали это таким образом) и получить местоположение файла, а затем использовать FileStream для его извлечения, будь то из локального компа, локального сервераили корпоративный сервер, если вы можете сделать это через LAN / WAN.Извлечение из интернет-адреса потребует другого механизма.

То, что я сделал бы, это прослойка преобразований.Чтобы преобразовать файл настроек из A в D, сначала преобразуйте его в B, затем в C, а затем в D. Это может показаться неэффективным, но это будет только в тех случаях, когда у пользователя крайне устаревшая версияпрограммного обеспечения;регулярные обновления из предыдущей версии будут проходить только один слой.Это также имеет чрезвычайное преимущество, заключающееся в том, что каждый слой закрыт для изменения;если у вас есть код для правильного преобразования версии A в версию B, вам НИКОГДА не придется возвращаться и, возможно, нарушать его, чтобы добавить логику обновления версии C.

Answer 3

Лучший способ справиться с обновлениями - делать это по одному шагу за раз.

Принимая ваш пример: Постройте путь обновления от A до B, а затем от B до C.

При тестировании апгрейда с А до С сначала нужно запустить от А до В, затем от В до С.

Это немного ограничит сценарии тестирования. Многие программы, которые я видел, обновляют таким образом. Это может привести к тому, что добавление поля в таблицу (обновление до B) приведет к немедленному удалению (обновление до C); но это небольшая цена, которую нужно заплатить, чтобы ограничить сценарии.

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