Недостатки использования фальшивых фреймворков во временном коде проекта

Question

Я работаю над шаблоном Prism для своей компании. Я хочу сделать данные времени разработки максимально простыми.

С этой целью я создаю класс Design, который наследуется от моего ViewModel. DesignViewModel вызовет конструктор моего ViewModel.

Конструкторы My ViewModel иногда используют методы и свойства призмы, такие как IRegionManager.Regions. Я подумываю сделать Stub для этого интерфейса, который будет использовать NSubstitute. Как это:

public class DesginRegionManager : IRegionManager 
{ 
    public IRegionManager CreateRegionManager(){return this;} 

    private readonly IRegionCollection regions; 
    public DesginRegionManager() 
    { 
     regions = Substitute.For<IRegionCollection>(); <-------- 
    }               | 
                   | 
    public IRegionCollection Regions {get { return regions; }} | 
}                | 
                   | 
// Using NSubstitute here ---------------------------------------- 

Я планирую сделать аналогичные вещи для IUnityContainer.

Я никогда раньше не использовал рамки Mocking во всех, кроме модульных тестов. Это плохая идея использовать его вот так?

Хотя он никогда не будет вызван в производственном коде, он добавит зависимость от NSubstitute для моего фактического приложения.

Есть ли недостатки в этом вопросе?

Answer 1

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

Неплохо ли использовать заменители для проектных целей?

Мой короткий ответ нет.

Не совсем идеально, но если у вас есть отдел дизайна (или кто-то, ответственный за элементы пользовательского интерфейса при продолжении кодирования), является хорошей практикой для изоляции кода, выполняемого пользовательским интерфейсом, из процесса разработки, поскольку вы сможете улучшайте свой интерфейс, даже если код, который будет выполняться в реальном времени, является ошибкой.

Когда я говорю о заменителях, я говорю о реальных экземплярах экземпляра, которые будут созданы во время разработки визуальной студией или смесью. (Я приведу образец в конце).

Неужели это плохая идея издеваться над этими элементами?

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

Положительная сторона этого является:

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

Отрицательная сторона этого:

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

Кроме того, ваш дизайнер (в случае наличия одного гуру-гуру) должен будет узнать, как работает адский nsubstitute (или насмешливая структура ваших предпочтений).

Если у меня была крышка для дизайнера, и вы показываете мне класс с определенным определением, который я мог бы реплицировать в сравнении с классом, определенным внешней библиотекой, называемой заменой, я могу сказать, что предпочитаю первый вариант, поскольку у меня не будет необходимости чтобы узнать что-нибудь еще, кроме бит C#. И даже так, я не буду пытаться коснуться этого кода.

Любые недостатки добавления nsubstitute в ваш проект?

До тех пор, пока вы используете DesignInstance правильно и ссылка на код с помощью mocks изолирована от фактической функциональности, и вы не пытаетесь заменить не виртуальные свойства, либо экземпляры с несколькими параметрами или закрытыми классами (в основном любое ограничение nsubstitute над чем заменить), вы будете в порядке, поскольку атрибуты дизайна будут выполняться в специальном режиме вашего кода.

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

Любые образцы?

Возможно, вы знаете, что писать, но здесь оно идет (а не призма).

<UserControl 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:d="http://schemas.microsoft.com/winfx/expression/blend/2008" 
    xmlns:vm="clr-namespace:Project.Namespace.ViewModels.DataSamples" 
    d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True, Type={x:Type NationViewModelSampleData}}"> 

    <StackPanel DataContext="{Binding Leader}"> 
     <TextBlock Text="{Binding FirstName}" /> 
     <TextBlock Text="{Binding LastName}" /> 
    </StackPanel> 
</UserControl> 

Если NationViewModel реализован интерфейс, как этот

namespace Project.Namespace.ViewModels 
{ 
    public interface INationViewModel 
    { 
     IPerson Leader { get; } 
     IEnumerable<IPerson> Citizens { get; } 
    } 

    public interface IPerson 
    { 
     string FirstName { get; } 
     string LastName { get; } 
    } 
} 

И Выборочные данные:

namespace Project.Namespace.ViewModels.DataSamples 
{ 
    public class NationViewModelSampleData : Project.Namespace.ViewModels.INationViewModel 
    { 
     public NationViewModelSampleData() 
     { 
      // You could have done something like this as well, but for this sample was more code to write. 
      // Leader = Substitute.For<IPerson>(); 
      // Leader.FirstName.Returns("John"); 
      // Leader.LastName.Returns("Doe"); 
      // or just... 
      Leader = new Person { FirstName = "John", LastName = "Doe" }; 

      Citizens = new IPerson[] 
         { 
          new Person { FirstName = "Malcolm", LastName = "Little" }, 
          Leader 
         }; 
      // You could have applied the mock to this section as well... again, more code for this scenario than just a simple real instance. 
     } 

     public IPerson Leader { get; private set; } 
     public IEnumerable<IPerson> Citizens { get; private set; } 
    } 
} 

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

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

Cheers!