5

私は個人的なプロジェクトとしてJavaScriptアプリケーションを書き始めました。このプロジェクトで単体テストを学び、使用したいと思っています。私は単体テストを書いた経験があまりありませんが、ジャスミンがこれを達成するのに役立つ優れたライブラリになることを読みました。

そうは言っても、私は最初のコーディングに少し熱心でした。私はアイデアを思いつき、それを実行しました。そのため、私のアプリケーションの構造は、私が望むほどOOではありませんでした。これにより、私は複数の大規模なリファクタリングの道を歩み始めました。弱いタイプの言語でリファクタリングすると、特にバグが再入しやすくなることがわかりました。

私が戻って、私が再導入したバグに対処しなければならないという事実は、私をユニットテストに憧れさせます。しかし、対照的に、コードベースの基盤を大幅に作り直しているという事実は、依然として私を躊躇させます。プロジェクトの単体テストを作成して、さらに再構築する必要があると判断したいだけです（これにより、「エラーの修正」の時点を過ぎてテストが非推奨になります）。

これは一般的な懸念事項ですか？私の「基礎」がそれのためのテストを書くのに十分安定する時点があるように私は感じます...しかしそれはテストをそれほど魅力的に聞こえないようにします。

4

1 に答える 1

4

現在のコードベースを「実験的」または「プロトタイプ」として扱うことを検討します。つまり、ほとんど破棄するものです。

コードベースのリファクタリングを計画している場合は、リファクタリングする前に、またはリファクタリングされたコードに対して単体テストを導入することをお勧めします。

現在のコードベースのテストを作成する利点は明らかです。リファクタリングされたコードベースをそれらに対して実行して、機能を検証できます。リファクタリング中に、おそらくテストをいくらか再構築する必要があるでしょうが、それは正常なことです。

テストを書き直すときにすべきでないことは、テストを削除することです。各テストのすべての最終アサーションを同じに保ちながら、他の方法でテストが機能する方法を置き換えるようにしてください。こうすることで、何をテストしているかをよりよく追跡できるようになり、新しい機能が同じように機能することを確認できます。

もちろん、元のコードを OO 以外の方法で書いた場合、それをうまくテストするのは難しいかもしれません。この場合、元のコードに対してより高いレベルのテスト (機能テスト) を作成するか、TDD 型のアプローチを使用してリファクタリングされたコードを作成するかを選択することをお勧めします。

機能テストを使用すると、アプリケーションの主要な機能のテスト カバレッジを得ることができます。単体テストほどきめの細かいテストはありませんが、テストをより簡単に記述でき、最終的にテストを大幅に変更する必要はありません。これには、Selenium などのツールを使用できます。

TDD アプローチを使用すると、おそらく作業量が最も少なくなります。新しく記述したコードのテスト カバレッジが良好であることを確認できますが、コードが古いコードと同じように機能することを手動で確認する必要があります。

于 2012-06-12T16:59:18.357 に答える