35日目

朝

今日の8番目の例は原理的に簡単ですが、彼が書いたコードは本当に怖いです.後のコードはますます怖いと言ってもいいですが、正直に言うと私はソフトウェアを作っているわけではありません.8割も使えません.
Gtestテクニック-9:パラメータ化「連合」とは、同じテスト要件を持つツール類を統合し、パラメータ化テストの際に「パラメータを設定する」(具体的にはその方法で、どのように測定するか)という意味です.この「入力パラメータ」には一般的にいくつかのタイプがあるので、サンプルコードを参照して、Combine()を使用する必要があります.(しかし、いったん使うと、あなたのツールクラスのインタフェースがすべて変更され、私たちのテストニーズにははるかに使えないような気がします)
-----------------------------------------------------------------------------------------------------------

// This sample shows how to test code relying on some global flag variables.
// Combine() helps with generating all possible combinations of such flags,
// and each test is given one combination as a parameter.

// Use class definitions to test from this header.
#include "prime_tables.h"

#include "gtest/gtest.h"
namespace {
     

// Suppose we want to introduce a new, improved implementation of PrimeTable
// which combines speed of PrecalcPrimeTable and versatility of
// OnTheFlyPrimeTable (see prime_tables.h). Inside it instantiates both
// PrecalcPrimeTable and OnTheFlyPrimeTable and uses the one that is more
// appropriate under the circumstances. But in low memory conditions, it can be
// told to instantiate without PrecalcPrimeTable instance at all and use only
// OnTheFlyPrimeTable.
class HybridPrimeTable : public PrimeTable {
     
 public:
  HybridPrimeTable(bool force_on_the_fly, int max_precalculated)
      : on_the_fly_impl_(new OnTheFlyPrimeTable),
        precalc_impl_(force_on_the_fly
                          ? nullptr
                          : new PreCalculatedPrimeTable(max_precalculated)),
        max_precalculated_(max_precalculated) {
     }
  ~HybridPrimeTable() override {
     
    delete on_the_fly_impl_;
    delete precalc_impl_;
  }

  bool IsPrime(int n) const override {
     
    if (precalc_impl_ != nullptr && n < max_precalculated_)
      return precalc_impl_->IsPrime(n);
    else
      return on_the_fly_impl_->IsPrime(n);
  }

  int GetNextPrime(int p) const override {
     
    int next_prime = -1;
    if (precalc_impl_ != nullptr && p < max_precalculated_)
      next_prime = precalc_impl_->GetNextPrime(p);

    return next_prime != -1 ? next_prime : on_the_fly_impl_->GetNextPrime(p);
  }

 private:
  OnTheFlyPrimeTable* on_the_fly_impl_;
  PreCalculatedPrimeTable* precalc_impl_;
  int max_precalculated_;
};

using ::testing::TestWithParam;
using ::testing::Bool;
using ::testing::Values;
using ::testing::Combine;

// To test all code paths for HybridPrimeTable we must test it with numbers
// both within and outside PreCalculatedPrimeTable's capacity and also with
// PreCalculatedPrimeTable disabled. We do this by defining fixture which will
// accept different combinations of parameters for instantiating a
// HybridPrimeTable instance.
class PrimeTableTest : public TestWithParam< ::std::tuple<bool, int> > {
     
 protected:
  void SetUp() override {
     
    bool force_on_the_fly;
    int max_precalculated;
    std::tie(force_on_the_fly, max_precalculated) = GetParam();
    table_ = new HybridPrimeTable(force_on_the_fly, max_precalculated);
  }
  void TearDown() override {
     
    delete table_;
    table_ = nullptr;
  }
  HybridPrimeTable* table_;
};

TEST_P(PrimeTableTest, ReturnsFalseForNonPrimes) {
     
  // Inside the test body, you can refer to the test parameter by GetParam().
  // In this case, the test parameter is a PrimeTable interface pointer which
  // we can use directly.
  // Please note that you can also save it in the fixture's SetUp() method
  // or constructor and use saved copy in the tests.

  EXPECT_FALSE(table_->IsPrime(-5));
  EXPECT_FALSE(table_->IsPrime(0));
  EXPECT_FALSE(table_->IsPrime(1));
  EXPECT_FALSE(table_->IsPrime(4));
  EXPECT_FALSE(table_->IsPrime(6));
  EXPECT_FALSE(table_->IsPrime(100));
}

TEST_P(PrimeTableTest, ReturnsTrueForPrimes) {
     
  EXPECT_TRUE(table_->IsPrime(2));
  EXPECT_TRUE(table_->IsPrime(3));
  EXPECT_TRUE(table_->IsPrime(5));
  EXPECT_TRUE(table_->IsPrime(7));
  EXPECT_TRUE(table_->IsPrime(11));
  EXPECT_TRUE(table_->IsPrime(131));
}

TEST_P(PrimeTableTest, CanGetNextPrime) {
     
  EXPECT_EQ(2, table_->GetNextPrime(0));
  EXPECT_EQ(3, table_->GetNextPrime(2));
  EXPECT_EQ(5, table_->GetNextPrime(3));
  EXPECT_EQ(7, table_->GetNextPrime(5));
  EXPECT_EQ(11, table_->GetNextPrime(7));
  EXPECT_EQ(131, table_->GetNextPrime(128));
}

// In order to run value-parameterized tests, you need to instantiate them,
// or bind them to a list of values which will be used as test parameters.
// You can instantiate them in a different translation module, or even
// instantiate them several times.
//
// Here, we instantiate our tests with a list of parameters. We must combine
// all variations of the boolean flag suppressing PrecalcPrimeTable and some
// meaningful values for tests. We choose a small value (1), and a value that
// will put some of the tested numbers beyond the capability of the
// PrecalcPrimeTable instance and some inside it (10). Combine will produce all
// possible combinations.
INSTANTIATE_TEST_SUITE_P(MeaningfulTestParameters, PrimeTableTest,
                         Combine(Bool(), Values(1, 10)));

}  // namespace

そして書く練習をしましょう.全体の意味は覚えていて、細部は忘れています.

午後

先生の言葉に従って、コードを書く考えを変えました.テストから設計し、「システム」の全体的な考えで考えてみると、確かに収穫が大きいです.特に、インタフェースと適用性を最終目的とする場合、単に「機能を実現する」ためではなく、考え方全体が異なります.元の时は确かに愚かで、何を考えて何を书いて、まったく计画していないで、再构筑してもコードをもっと冗長にするだけで、その时に変えた时はまだ良い感じがしたとは信じられません.  最後の計画は先月、黒河でデバッグしたときに他の人のapiを使ったときの感覚で、コード設計を行うことで、最も明らかな特徴は

ClientとServerエンド

を区別しない

は、タイプではなく機能別にライブラリファイルを分類します.

コード、関数は簡略化され、私たちが今提供しているフレームワークであり、apiであり、プログラムを書くのではないことを覚えておいてください.

もちろん、最後にいくつかのサンプルとtest、readmeなどのファイル

を書きます.
  このように见ると、私の前の混沌とした复雑な仕事を明确にして、それから确かにあまり长くかけないで终わることができるようで、それから自分のAPIでプログラムの设计を体験して、このようにコードを书くのは一心不乱に考えて考えを実现することができて、后で底层を调整するのではありませんて、前のコードはあまりにもspecificですためです.それから使用した不足によって更に修正をして、最后に先生の学友に体験します!