目的がわからないコードのテストを書く

私は最近、ブラックボックスのリファクタリングを完了しました。テストする方法がわからないので、チェックインできません。

高レベルでは、クラスBから値を取得する初期化を含むクラスがあります。クラスBが「空」の場合、適切なデフォルトが生成されます。クラスBを同じデフォルトに初期化するメソッドにこの部分を抽出しました。

どちらのクラスの目的/コンテキスト、またはそれらがどのように使用されるかについてはまだ解明していません。そのため、空のクラスBからオブジェクトを初期化することはできませんし、正しい値を持っている/正しいことを行っていることを確認してください。

私の最善のアイデアは、元のコードを実行し、初期化されたメンバーに応じてパブリックメソッドの結果をハードコードし、それに対して新しいコードをテストすることです。この考えに漠然と不快感を覚える理由を明確に述べることはできません。

ここにはより良い攻撃がありますか？

元気です！

多くの場合、コンポーネントをリファクタリング可能にするには、自動化された回帰テストを作成するのが最善の方法です。驚くかもしれませんが、入力と出力の「インターフェース」（その言葉の一般的な意味）を理解している限り、コンポーネントが内部で何をするのかを完全に理解せずにそのようなテストを書くことができます。これは、クラスだけでなく、本格的なレガシーアプリケーションに対しても過去に数回行いました。これは、十分に理解していないことを壊さないようにするのに役立ちました。

ただし、十分なテストデータを用意し、そのコンポーネントのユーザーの観点からソフトウェアの機能をしっかりと理解しておく必要があります。そうしないと、重要なテストケースを省略するリスクがあります。

リファクタリングを開始する前に自動テストを実装することをお勧めします。その後ではなく、小さなステップでリファクタリングを行い、各ステップを検証できます。リファクタリング自体がコードを読みやすくする必要があるので、少しずつ内部の理解を深めるのに役立ちます。したがって、このプロセスの注文手順は

1. 「外部から」コードを理解する、
2. 回帰テストを書く、
3. リファクタリングは、コードの内部のより良い理解につながります

単体テストを記述する重要な理由は、コンポーネントAPIを何らかの形で文書化することです。ここでは、テスト中のコードの目的を理解していないことが本当に問題です。コードカバレッジはもう1つの重要な目標であり、どの実行ブランチが存在し、どのようにトリガーされるかを知らずに達成することは困難です。

ただし、状態をきれいにリセットする（または新しいテストオブジェクトを毎回作成する）ことが可能な場合は、システムにほとんどランダムな入力を送り、出力を観察する「ゴミ箱からゴミ箱へ」タイプのテストを書くことができます。

そのようなテストは、失敗した場合に、その理由と深刻さを言うのが複雑なため、維持するのが困難です。報道は疑わしいかもしれません。しかし、彼らはまだ何もないよりもはるかに優れています。そのようなテストが失敗すると、開発者は最新の変更をより注意して修正し、できればバグを見つけることができます。