0

だから私は、自分の開発に対して、よりテストと行動主導のアプローチに自分自身を変えようとしています。それは私にとって良いことであり、これまでに使用したいくつかのプロジェクトで良い結果が得られました.

私の現在のプロジェクトは FUSE ベースのファイルシステムです。基本的なファイルシステム アクセスにいくつかの機能を追加したいので、FUSE が適しているように思えました。私が実際に行う必要があるのは、適切なインターフェイスに適合する一連の関数を実装し、適切にラップして実行することだけです。

ただし、最初にテストしてください。アプリ全体がどのように機能するかについての基本的な期待を示す一連のキュウリ機能を既に作成したので、今度は内部のテストに取り掛かります。

これで、インターフェース用に作成する必要のある各関数の単体テストを作成してから、インターフェースのコーディングに取り掛かることができますが、それは過度にテスト主導型とは思えません。確かにテストは存在しますが、実際に物事を動かすのはインターフェイスです。

私はこれについて間違っていますか?それとも期待しすぎですか?

これがコミュニティ wiki であるべきだと思われる場合は、コメント欄で「何を」を教えてください。これ正しい答えであるかどうかは、私には判断できません。

4

3 に答える 3

1

ステップ 1. インターフェースがしなければならないことを 1 つ挙げてください。ひとこと。

ステップ 2. それが 1 つのことを行うことをどのように証明しますか?

ステップ 3. インターフェイスが実際にその 1 つのことを行うことを証明するテストを作成します。

ステップ 4. テストを実行します -- テストは失敗します。あなたは実際にインターフェースを書いていません。

ステップ 5. インターフェイスをコーディングします。

ステップ 6. テストに合格します。

インターフェイスが実行する必要がある次の処理に進みます。

これは、すでに設計した関数とはほとんど関係ありません。これは、インターフェイスに必要な外部から見える機能に完全に焦点を当てています。あなたの機能が正しいことがわかるかもしれません。または、これらの機能を過度に設計したことが判明する場合があります。または、それらを設計しきれなかった。ポイントは、コンポーネントがしなければならないことと、コンポーネントがしなければならないことを証明するためのテストから設計を推進することです。

于 2010-07-16T18:01:16.087 に答える
0

Rubyだけに焦点を当てている場合でも、rspecの本にはBDDサイクルに関する優れた紹介があります。

于 2010-07-16T19:11:43.877 に答える
0

基本的なファイルシステム アクセスにいくつかの機能を追加したいので、FUSE が適していると思われました

ヒューズ fs を開発するのは難しいです。2 つの主な問題は、非常に難しいデバッグとマルチスレッドです。また、fsのテストに問題がありました(そして現在も問題があります)。多分inotifyはあなたの要件を満たすでしょう。

于 2010-07-22T08:29:55.960 に答える