Googleテストエッセンス(1)-実装ではなく動作をテスト
5196 ワード
Your trusty Calculator class is one of your most popular open source projects, with many happy users:
クラスCalculatorはあなたが最も人気のあるオープンソースプロジェクトの一つであり、多くのユーザーがいます.
You also have tests to help ensure that it works properly:
また、このクラスについてテストを書いて、このクラスが正常に動作していることを確認します.
However, a fancy new library promises several orders of magnitude speedup in your code if you use it in place of the addition operator. You excitedly change your code to use this library:
しかし、ある日、以前の加算操作の代わりにこのライブラリを使用すると、コードのパフォーマンスがいくつかのレベルに向上することを保証する奇抜な新しいライブラリ(Library)があることに気づきました.コードを変更してこのライブラリを使用します
That was easy, but what do you do about the tests for this code? None of the existing tests should need to change since you only changed the code's implementation, but its user-facing behavior didn't change. In most cases, tests should focus on testing your code's public API, and your code's implementation details shouldn't need to be exposed to tests.
これは簡単ですが、テストコードはどうしますか?修正は必要ですか?もちろん、コードの実装だけを変更し、コードの使用者向けの動作を変更しないため、変更する必要はありません.ほとんどの場合、テストはあなたのコードをテストする共通のAPIに集中するべきで、コードの具体的な実装は隠すべきで、テストされるべきではありません.
Tests that are independent of implementation details are easier to maintain since they don't need to be changed each time you make a change to the implementation. They're also easier to understand since they basically act as code samples that show all the different ways your class's methods can be used, so even someone who's not familiar with the implementation should usually be able to read through the tests to understand how to use the class.
テストは実装とは独立してメンテナンスが容易になります.機能の実装を変更するだけで、caseを毎回変更する必要はありません.また、このようなテストも理解しやすいです.これらのテストは基本的にあなたのCode samplesとして、あなたのクラスを使用する方法のすべての方法を示すことができるので、コード実装に慣れていない人がいても、あなたのテスト例を読むことで、これらのクラスをどのように使用するかを理解することができます.
There are many cases where you do want to test implementation details (e.g. you want to ensure that your implementation reads from a cache instead of from a datastore), but this should be less common since in most cases your tests should be independent of your implementation.
もちろん、Casesは具体的なコードの実装の詳細をテストしたいと思っています(例えば、DatastoreではなくCacheからデータを読んでいることを確認したいと思っています)が、これはあまり一般的ではありません.多くの場合、あなたのテストはあなたのエージェントとは独立して実装されるべきです.
Note that test setup may need to change if the implementation changes (e.g. if you change your class to take a new dependency in its constructor, the test needs to pass in this dependency when it creates the class), but the actual test itself typically shouldn't need to change if the code's user-facing behavior doesn't change.
Test Setupは、クラスを変更して構造関数に依存させる場合など、変更を実現する可能性がありますが、実際には、コードがユーザーにとって動作しない限り、Testは変更する必要はありません.
このブログをご覧になって、何か得になったと思ったら、以下の[おすすめ]をクリックしてください.
このブログを転載したい場合は、出典を明記してください
本文にご意見やご提案がございましたら、メッセージをお待ちしております
PS:PowerMock交流群(332365691)へようこそ、一緒に交流しましょう.
クラスCalculatorはあなたが最も人気のあるオープンソースプロジェクトの一つであり、多くのユーザーがいます.
public class Calculator {
public int add(int a, int b) {
return a + b;
}
}You also have tests to help ensure that it works properly:
また、このクラスについてテストを書いて、このクラスが正常に動作していることを確認します.
public void testAdd() {
assertEquals(3, calculator.add(2, 1));
assertEquals(2, calculator.add(2, 0));
assertEquals(1, calculator.add(2, -1));
}However, a fancy new library promises several orders of magnitude speedup in your code if you use it in place of the addition operator. You excitedly change your code to use this library:
しかし、ある日、以前の加算操作の代わりにこのライブラリを使用すると、コードのパフォーマンスがいくつかのレベルに向上することを保証する奇抜な新しいライブラリ(Library)があることに気づきました.コードを変更してこのライブラリを使用します
public class Calculator {
private AdderFactory adderFactory;
public Calculator(AdderFactor adderFactory) { this.adderFactory = adderFactory; }
public int add(int a, int b) {
Adder adder = adderFactory.createAdder();
ReturnValue returnValue = adder.compute(new Number(a), new Number(b));
return returnValue.convertToInteger();
}
}That was easy, but what do you do about the tests for this code? None of the existing tests should need to change since you only changed the code's implementation, but its user-facing behavior didn't change. In most cases, tests should focus on testing your code's public API, and your code's implementation details shouldn't need to be exposed to tests.
これは簡単ですが、テストコードはどうしますか?修正は必要ですか?もちろん、コードの実装だけを変更し、コードの使用者向けの動作を変更しないため、変更する必要はありません.ほとんどの場合、テストはあなたのコードをテストする共通のAPIに集中するべきで、コードの具体的な実装は隠すべきで、テストされるべきではありません.
Tests that are independent of implementation details are easier to maintain since they don't need to be changed each time you make a change to the implementation. They're also easier to understand since they basically act as code samples that show all the different ways your class's methods can be used, so even someone who's not familiar with the implementation should usually be able to read through the tests to understand how to use the class.
テストは実装とは独立してメンテナンスが容易になります.機能の実装を変更するだけで、caseを毎回変更する必要はありません.また、このようなテストも理解しやすいです.これらのテストは基本的にあなたのCode samplesとして、あなたのクラスを使用する方法のすべての方法を示すことができるので、コード実装に慣れていない人がいても、あなたのテスト例を読むことで、これらのクラスをどのように使用するかを理解することができます.
There are many cases where you do want to test implementation details (e.g. you want to ensure that your implementation reads from a cache instead of from a datastore), but this should be less common since in most cases your tests should be independent of your implementation.
もちろん、Casesは具体的なコードの実装の詳細をテストしたいと思っています(例えば、DatastoreではなくCacheからデータを読んでいることを確認したいと思っています)が、これはあまり一般的ではありません.多くの場合、あなたのテストはあなたのエージェントとは独立して実装されるべきです.
Note that test setup may need to change if the implementation changes (e.g. if you change your class to take a new dependency in its constructor, the test needs to pass in this dependency when it creates the class), but the actual test itself typically shouldn't need to change if the code's user-facing behavior doesn't change.
Test Setupは、クラスを変更して構造関数に依存させる場合など、変更を実現する可能性がありますが、実際には、コードがユーザーにとって動作しない限り、Testは変更する必要はありません.
テキストアドレス
Testing on the Toilet: Test Behavior, Not Implementation
このブログをご覧になって、何か得になったと思ったら、以下の[おすすめ]をクリックしてください.
このブログを転載したい場合は、出典を明記してください
本文にご意見やご提案がございましたら、メッセージをお待ちしております
PS:PowerMock交流群(332365691)へようこそ、一緒に交流しましょう.