Question

在当前的项目中，我正在与一位坚持认为代码生成对单元测试不利的客户进行交易。他们团队中的一些技术/评估人员是非常有经验的开发人员，所以这让我感到惊讶。这么多，在看到他们的个人资料后，我正在就一个我不会质疑的主题（即自动化）征求社区意见。

标题是指用于创建单元测试的代码生成。根据场景，可以在不同的范围内完成。我自己编写了这个特定的库，并认为它在分支，复杂性，可维护性等方面非常简单。下面列出了一个摘要来说明相同的内容。

有问题的库是一个通用的有限状态机，它使用两个枚举来确定可能的states和commands列表。命令用于指定抽象事务，而在没有命令的情况下也可以请求显式任意状态，只要它是合法的。状态示例包括Processing，Cancelled，WaitingForUserInput等。命令示例包括WakeUp，Sleep，StartProcessing等。

取消如下：

// Both [TState] and [TCommand] will ALWAYS be enumerations.
public abstract class StateMachineBase<TState, TCommand>: IDisposable
{
    public delegate void DelegateStart (StateMachineBase<TState, TCommand> sender, EventArgs e);
    public delegate void DelegateStop (StateMachineBase<TState, TCommand> sender, EventArgs e);
    public delegate void DelegateTransitionRequest (StateMachineBase<TState, TCommand> sender, TransitionRequestEventArgs<TState, TCommand> e);
    public delegate void DelegateTransitionComplete (StateMachineBase<TState, TCommand> sender, TransitionCompletedEventArgs<TState, TCommand> e);

    public event DelegateStart OnStart = null;
    public event DelegateStop OnStop = null;
    public event DelegateTransitionRequest OnTransitionRequest = null;
    public event DelegateTransitionComplete OnTransitionComplete = null;

    private readonly object _SyncRoot = new object(); // Thread safety.
    public bool Running { get; private set; }
    public TState State { get; private set; }
    private TCommand Command { get; set; }
    private List<Transition<TState, TCommand>> AllowedTransitions { get; set; }

    // Will not work if the machine is running.
    protected void AddTransition (TState from, TState to, TCommand command) { ... }
    public void Start () { ... }
    public void Stop () { ... }
    public bool CanTransit (TState state) { ... }
    public bool CanTransit (TCommand command) { ... }
    public bool Request (TState state) { ... }
    public bool Request (TCommand command) { ... }
}

我确实意识到在某些情况下，使用代码生成可能会破坏编写单元测试的目的，但我相信很多开发人员确实在特定场景中使用它。我想，如果我自己编写了库，我应该能够通过手工或反射来获得正确的单元测试。

问题是，在这种情况下使用代码生成是否明智？如果没有，我可以忽视什么意想不到的后果？

Answer 1

我非常相信代码生成对于测试套件基础架构的创建是有意义的，而不是业务逻辑。基础设施（以及上面示例中的示例）必须以某种方式实现，但应该是人（最好是知道他们正在做什么的人）决定测试用例的数量，目的是每个测试用例，最后是测试用例逻辑的实现。

我会与你们的同事讨论如何就不可协商的基础设施代码与测试用例作者之间的分歧达成共识。您应该能够使用前者的代码生成和手动编码后者来销售它们。

对于简单的有限状态机，使用代码生成进行单元测试有多么有效/危险？

1 个答案: