web-dev-qa-db-ja.com

機能構成と配管をテストする必要がありますか?

ユニットテストでは、最初にテストを記述してからコードを記述する必要があります。一方、F#(およびほとんどの関数型言語)では、次のように一部のコードが非常に短くなります。

let f = getNames
>> Observable.flatmap ObservableJson.jsonArrayToObservableObjects<string>

または:

let jsonArrayToObservableObjects<'t> =
    JsonConvert.DeserializeObject<'t[]> 
    >> Observable.ToObservable

そして、私が後者の関数のために行った最も簡単なプロパティベースのテストは次のとおりです:

 testList "ObservableJson" [
        testProperty "Should convert an Observable of `json` array to Observable of single F# objects" <| fun _ -> 
            //--Arrange--
            let (array , json) = createAJsonArrayOfString stringArray

            //--Act--
            let actual = jsonArray
                         |> ObservableJson.jsonArrayToObservableObjects<string> 
                         |> Observable.ToArray 
                         |> Observable.Wait


            //--Assert--
            Expect.sequenceEqual actual sArray
    ]

配置部分に関係なく、テストはテスト対象の関数よりも多いため、テスト対象の関数よりも読みにくいです。

  • 量産コードよりも読みにくい場合のテストの価値は何でしょうか?

一方:

  • 2つの関数の合成は、それ自体が1つの単位と見なすことができる別の関数です。
  • 複数の機能を組み合わせた機能をテストしないようにしても安全なのでしょうか?
  • 代わりに、統合および受け入れレベルでテストする必要がありますか?
  • そして、それらは短いが複雑な操作を行うとどうなりますか?
5
Mohsen

量産コードよりも読みにくい場合のテストの価値は何でしょうか?

ユニットテストでは、コードを検証しない場合、動作を検証します。

これを行う理由は2つあります。

  1. 実装された動作を文書化します。
  2. (不要な)変更を検出します。

また、(単体)テストのサイズではなく、読みにくくなっています。

ユニットテストに関する重要な点は、テストされたユニットの動作に関する単一の仮定を検証することです。テストの読みやすさは、この仮定がどれだけ適切に記述されているかにあります。

2つの関数の合成は、それ自体が1つの単位と見なすことができる別の関数です。

ユニットのサイズは重要なポイントです。しかし、そのためのハードリミットはありません。 ユニットはアプリケーションコードの一部であり、変更する理由は同じです

複数の機能を組み合わせた機能をテストしないようにしても安全なのでしょうか?

場合によります。その組み合わせの背後にあるロジックはありますか、それとも単純なチェーンですか?前者にはいくつかのテストが必要ですが、後者には必要ありません。

それらは統合および受け入れレベルでテストする必要がありますか?

どちらのタイプのテストにも異なる目的があります。

  • 統合テストは、技術レベルでのユニットのコラボレーションを目的としています。つまり、アプリケーションの配線に問題があり、ユニットのAPIが適切かどうかを検出します。これはまさに「順次呼び出し」がテストされる場所です。

  • 受け入れテストでは、アプリケーションが書面の要件に準拠していることを確認します。そのレベルでは、具体的な単位は関係ありません。

そして、それらは短いが複雑な操作を行うとどうなりますか?

すでに述べたように、動作を検証するため、関数を(ユニット)テストする場合、サイズは重要ではありません。

5
Timothy Truckle