1

現在のプロジェクトで、コード生成は単体テストにとって悪であると主張するクライアントを扱っています。チームの技術/評価スタッフの何人かは非常に経験豊富な開発者であるため、これには驚きました。そのため、彼らのプロフィールを見た後、他の方法では質問しないテーマ (自動化など) についてコミュニティの意見を求めています。

タイトルは、単体テストを作成するためのコード生成に関するものです。これは、シナリオに応じてさまざまな範囲で実行できます。私はこの特定のライブラリを自分で作成しましたが、分岐、複雑さ、保守性などの点で非常に単純であると考えています。同じことを説明するための要約を以下に示します。

states問題のライブラリは、可能なとのリストを決定するために 2 つの列挙を使用する一般的な有限状態マシンです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) { ... }
}

場合によっては、コード生成を使用すると単体テストを作成する目的が損なわれる可能性があることは認識していますが、多くの開発者が特定のシナリオでコード生成を使用していると確信しています。ライブラリを自分で作成した場合、手動でもリフレクションでも、単体テストを正しく行うことができるはずです。

問題は、この場合にコード生成を使用するのが賢明かどうかです。そうでない場合、どのような意図しない結果を見逃す可能性がありますか?

4

1 に答える 1

1

コード生成はテスト スイート インフラストラクチャの作成には意味がありますが、ビジネス ロジックには意味がないと強く信じています。インフラストラクチャ（および上記の例にその例があります）は特定の方法で実装する必要がありますが、テストケースの数、目的を決定するのは人間（できれば自分が何をしているのかを知っている人間）でなければなりません各テスト ケース、最後にテスト ケース ロジックの実装です。

交渉の余地のないインフラストラクチャ コードと、テスト ケースの作成者に委ねられているものとの間の分割について、同僚に意見を求めます。前者はコード生成を使用し、後者は手作業でコーディングすることで販売できるはずです。

于 2012-09-25T03:09:48.923 に答える