Serviceを読んで理解し、同意したものとみなします。すべて12テスト駆動開発に関する疑問TDDはテストのためのテクニックではなく開発のためのテクニックです。クラスなどの小さな部品を実装する際に、そのAPI(publicメソッドなど)を呼び出す簡易的なテストコードをあらかじめ書いておき、そこから実際に対象クラスを実装していきます。することで、本当に欲しい部品を設計しながら実装することができます。簡単なバグを見つけ出すのにも役に立ちますが、テストケースの網羅はしません。その際に、テストコードは呼び出したメソッドの戻り値がなんであるかを簡単なアサーション(等しいかどうか、大小、nullかどうかなど単純な真偽チェックが多い)を用いてチェックすることが多いです。テスト側でロジックを持たせるわけではないので、テスト側のテストは不要です。個の銅バッジ8DIコンテナを使うメリットが分からない歴史には沿っていないと思いますが、次のように考えてみました。それをコンポーネントに切り分けていく。インターフェイスを挟む。替えはきくが、内部を変更する必要がある。その代りオブジェクト生成が複雑になり、その生成ロジックが分散している。依存性の注入までは小規模のコードでもわかりやすく、実際テストに便利だったりします。一方で、それぞれのオブジェクトへの依存が少ない、質問に例示されたようなコードでは「同じ生成ロジックが分散する」と感じにくいですし、コンテナを使うメリットは薄いかもしれません。この部分は具象クラスであるSolクラスに依存してしまいます。Sol()する箇所も多くなります。SolクラスをKyクラスに変更したくなった場合、修正箇所が多くなりメンテナンス性が低くなります。Sol()する箇所が多くなると非常に辛くなってきます。構造に変更があった場合、修正が大変です。書き換えてそちらが標準入力から得た内容でテストした方が健全な気がします。個の銅バッジ4テスト駆動開発に関する疑問TDDの方法論に従うと、自ずと「テストに対するテスト」が必要な状況にはなりにくくなります。これがTDDの大きなメリットです。テストが必要なほど複雑なテストを書くのではなく、簡潔で誤りの余地がないテストコードを積み重ねていくのがTDDの方法論です。TDDでは一般に何らかのテストフレームワークを使用します。事前準備と後片付けをテストコードと分離したり、複雑な振る舞いをモックを用いて簡略化したり、専用の文法でテスト条件を記述したりすることができ、これによりテストコードを簡潔に保ち続けることができます。簡潔なコードであればバグが入り込む余地はすくなくなります。個の銅バッジ4Scalaアプリに対して、クラスの依存関係をテストする方法を教えてください自己解決したので記録します。このような用途でScalaに対して使えるフレームワークとしてArchUnitがあります。ArchUnitは基本的にはJava向けに作られていますが、ScalaやKotlinでも利用可能です。Scalaに適用する場合、適当なテストフレームワーク(以下のサンプルではscalatest)の中で呼び出して使う形になります。Injection)一般論としては、「ソフトウェア・コンポーネント間の依存性軽減」が目的でありメリットでもあると思います。コンポーネント間の依存性が小さくなる(モジュール結合度が小さくなる)ことの副次効果として、部品単位での単体テストのやり易さや、部品の再利用性向上も挙げられます。大規模ソフトウェア開発でこのようなメリットが歓迎されます。一方で依存性軽減の実現には、インターフェイスのような抽象レイヤを追加する必要があり、実装面ではオーバーヘッドがあることも確かです。万能なソフトウェア設計という物は存在しませんから、対象や状況に応じて採用可否を判断すべきですね。個の銅バッジ3Rspecのフィーチャーテストが失敗したりしなかったり回答というわけではないですが、自分も似たような問題にぶつかったので、問題を特定したやりかたを共有します。問題が出るシード値を特定します。Rspecを実行すると以下のように出力されます。(再現したりしなかったりするのであれば実行順以外の要因がある可能性があります)。テストに失敗するシード値を絞り込んだらそれをメモします。次に、失敗の原因となるファイルを特定します。{対象ファイル相対パス}で特定のファイルだけテストを実行出来ます。エラーでテストできない自己解決してしまいました。形のハッシュをパラメータにしないといけませんでした。個の銅バッジ3ESLintのno-unused-expressionsの直し方chaiとESLintのno-unused-expressionsルールは相性が悪く、chaiを使おうとするとどうしてもno-unused-expressionsに引っかかってしまいます、そこで、chaiを使う場合は後者を無効にする必要があります。そのためには、テストコードの先頭に次のコメントを書くとよいです。これは、そのファイル内でESLintによるno-unused-expressionsのチェックを無効にするという指示です。この記法については、ドキュメントのここに説明があります。個の銅バッジ2Meteor+mochaでテストが実行されないmeteor-mocha-webはtests/mocha/の下にあるファイルしかロードしないので、テストコードの置き場所を変える必要があります。trueを付けるとJSの処理が終わる前にRSpec側が先に進んでしまい、本来通るはずのテストがパスしない、もしくはタイミングによってパスするときと失敗するときがある、ということは僕も良く体験しています。トラブルシューティングの方法としては以下のようなことを良く試します。長さのsleepを入れてみます。これで毎回テストがパスするようならRSpec側を適当にsleepさせる必要があると言うことです。sleep秒数が長すぎるとテストの実行に時間がかかるので、0.5や1など、テストが失敗しないレベルの短い秒数を指定してください。以下サンプルコードです。これだとPATH環境変数だけスタブするというような事が出来ました。