テスト駆動開発-カートか馬か？

テスト駆動開発（TDD）は、多くの利点を備えた紛れもなく優れたテクノロジーです。 応用開発者は、プロジェクトの規模や関係する専門家の数に関係なく、TDDを大量にフォローしません。 しかし、このアプローチには熱心な支持者もおり、常識や生産の必要性だけでなく、その実装の無条件に成功した例にも訴える用意があります。 これらの謝罪者の1人は、開発に対するTDDのプラスの影響の程度について語るだけでなく、ソースコードとサンプルスクリプト（このブログで ）まで、この手法の実装と厳格な日常使用の専門知識も共有しているAlexander Lyulinです。 ただし、TDDの原則に従うことの主な障害は、予想通り、一連の純粋に心理的な態度です。 「ハード会話」モードでは、テスト駆動開発の必要性についてアレクサンダーと話します。



テスト駆動開発-ファッションに従う試み？ 他の人のアプローチのブラインドコピー？



「すぐに決めましょう」。 私はその古典的な意味でTDDを使用しません。 ここにウィキペディアを引用しないでください！ 一般に、専門家が百科事典の記事を行動の指針とみなすことはまずありません。 成功したプロジェクトの実装の一環としてアプローチを「苦しめた」ため、「他の人のアイデアの愚かな使用」ではなく、実際の経験があります。 むしろ、TDDの統合と、ソフトウェアの開発方法に関する独自のアイデアを使用します。 これらの「外部のアイデア」は非常に頭の良い人からのものであっても、実際の企業、既存のチーム、開発および品質保証戦略に批判的に評価し、適応させる必要があります。 しかし、私は引き続き「TDD」と言います。「テストによる開発」のプロセスを指します。



TDDは、すべてを逆さまにする試みです。 エンジニアリングの古典では、インストール/技術システム/機械/ユニットが最初に作成されます。 もちろん、設計の際にはテスト方法論を念頭に置いていますが、それでもプログラマーは特別な種類のエンジニアですか？ 遺伝的欠陥？ あなたはそのようにあなた自身を考慮しませんか？









それはすべて定義に依存します-「頭」とは何か、「足」とは何ですか。 そしてご存じのように、最も科学的な議論は用語に関する議論です。 テスト方法論を自給自足で深く発達した規律として語った場合、それが産業規模であるとは言えません。 その後、彼女は事実上あらゆる場所に存在し、原則的に論争はありません。 しかし、これは、実際には、たとえばコーヒーメーカー、芝刈り機、または自転車（「自転車」と混同しないように）を作る他のエンジニアと私たちを根本的に区別しません。







自分は「遺伝的に欠陥がある」と考えていますか？ 職業のために、一部、はい。 したがって、私は必ず良くなるように努力しています。 ソフトウェア開発はエンジニアリングの専門家ですので、突然自分をスーパーマンやある種のクリエイターと見なさないでください。 私たちは職人です（ユニットを除く）。これは認識され、調整されなければなりません。 そして、許容範囲、図面、テスト手順など、通常の（遺伝的に欠陥のない）エンジニアになろうとします。



TDD-開発者のイニシアチブを束縛します。 すでに開発者自身がプロセスを制御しているわけではありませんが、タスクは「雪玉でそれに陥ります」？ 心理的な不快感はありますか？ 私たちのプログラマーは今ではクリエーターではなく、機能を実装するための心のないマシンですか？



それどころか、TDDは何も制約しませんが、より生産的に作業できるようにします。 もちろん、「生産的」とは「より多くの作業」を意味します。 1つのクラスの代わりに、設計中のクラスとそのテストの2つを作成する必要があります。 TDDは、イニシアチブの人々のためのものです。 仕事が大好きな人。 最適化（=作業時間の節約）したい場合、これはすでに「ローファー用」という碑文が付いています。 潜在的なローファーや就業時間中に怠idleな練習をしている人は、これ以上読むことはできません。







開発者を制御するのは誰もいない、彼は自分自身を制御する-「手を打つ」 しかし、これはマゾヒズムではありません。 その見返りに、開発者は何か重要なものを手に入れます-明日、彼らのプロに対する安定感と自信。 そして、クリエイターとして-彼は2倍の量を作成します。 「プラウ」ではなく、作成します。 彼はすきを少なくしました。 明確化のために次の質問を楽しみにしています。



TDD-実装の品質ではなく、瞬間的な機能に焦点を当てています。 コードの品質についてどのように説明できますか？ システムアーキテクチャはどうですか？ プログラムコードの観点から見ると、「オリビエサラダ」は、味と色が異なる細かくカットされたピースの機械的な混合物ですか？ 大きな山に折り畳まれたビネグレットは、建築の完璧で建設的な品質を象徴できると思いますか？



これは絶対に真実ではありません。 品質と安定性が最重要です。 ちょうど、「機能」があります-「バグ」ではなく「機能」であることを確認するテストがあります。 TKに分類されなかったもの、テストに分類されなかったもの、機能のどこから来るのでしょうか？ この方法でのみ：顧客の希望は作業明細書に表現され、そこからテストに流れ込み、そのときだけ機能が現れます。







建築について...建築は普遍的で価値のあるものではありません。 そして、特効薬はありません。 そして、悪い弾丸でできているものではありません。 私はシステムのアーキテクチャを知っています、なぜなら 私はそれを15年間やっていますが、UML図面のおかげで完全に知っています。 UMLダイアグラム形式の設計ソリューションの完全なセットがあります。 しかし、ここではすべてを念頭に置いていない可能性があります。 これをすべてメモリに復元する方法は？ 特定のテストを見てください。

テストは「アーカイブされたメモリ」であり、「ドキュメント」と「ユースケース」です。



同時に、テストはプロジェクトコードに比べてより安定しており、不変です。 コードが生まれ変わりました。 進化します。 死にかけています。 テストでは、これははるかに少ない頻度で発生します。 アーキテクチャとテストに利害の対立はありません。 また、バンドル内のコードよりも重要です。







TDDは反抗的なIT奴隷を鞭打つ惨劇ですか？ これは、「開発者」と誇らしげに呼ばれる自由愛好家向けの「評議会」のようなものですか？ 開発者は考えるべきではありません。 あなたの仕事は、ストラップを引っ張り、シャフトで計画を実行することです！ 上からあなたから与えられたテストを見て、イニシアチブをとろうとしないでください！



だから...「管理」（総局、特に顧客）は、どのテクノロジーが使用されているかを気にしません（まれな例外を除き、私たちは望んでいません）。 一般的に、誰も動かず、開発者はそこで「内部」で何をしますか。 RUP、TDD / ShmeDD、アジャイル/スーパーアジャイルなどを使用します...







上記の「利害関係者」全員にとって-結果はプロセスではなく重要です。 健全なボスはTDDを課しません。 彼は開発者の迷惑ではなく、結果を必要とします-「この賢い人は再び私たちにいくつかの新しいチップを課します。」 賢い上司...本当に賢い（ITでは他の分野よりも頻繁に）、開発者自身にこの必要性を感じさせることができます。 これが唯一の方法であり、そうでなければ行き止まりです。



上記のテストはありません。 テストは開発者の内部問題です。 そして、テストが良くなり、テストが多ければ多いほど、開発者は「よりよく眠ります」。 そして、彼らはカーペットで呼ばれることが少ない。 テストは開発者向けであり、ボス向けではありません。



TDDは、能力のない人々によるコーディングであり、開発者にとって異質な独自のイデオロギーを促進する試みです...彼ら自身の、製品開発戦略に対するしばしば誤ったビジョン。



もう一度。 テストは、「ディレクター」、管理者、または顧客によって指示されることはありません。 テストは開発ツールです。 テストは、開発者と品質グループの「内部キッチン」です。 他のすべての「利害関係者」はTKで運営されています。 まあ、または「スクリーン」。 最大...テストと「開発戦略」はまったく相関しません。



TDDテクニックに従う義務があったと仮定しますが、多くの人がTDDテクニックを使用しなくても快適であると認めなければなりません。 さて、「計画-実施-テスト-テスト」を行ったとき、これは通常の技術と比較して何をもたらしますか？ 上司にとっての「美しいおとぎ話」は、「高度なアプローチを使用していますか？」



あなたはTDDのそのような頑固な相手になることができます！ テストを「義務付ける」ことは不可能です。 説得することしかできません。 誰かがテストなしで快適に感じる場合、それは次のことを意味します：

-彼のプロジェクトはそれほど複雑ではありません。

-彼は実際のユーザーですべてをテストします（運が悪い）

-彼は天才です。

-彼は一人で働いています。

鏡を見てカテゴリーを選択しましょう。







繰り返しますが、「テイルズ」-いいえ、ボス-すべて同じで、結果、条件、品質が必要です。



私はテストをめちゃくちゃにしました。 私は彼らのために機能コードをカスタマイズし始めました（しぶしぶ）。 その結果、テストが誤って考案されたことが判明しました。 無駄ですか？



その「ファックアップ」は必要ありません。 1つの機能-1つのテスト。 繰り返します。 機能はテストを生成し、テストは機能を生成します。 XP、キスの原則。



しかし、「厳しい課題」の形を獲得した「テスト」が互いに矛盾し始めることは起こりませんか？



これは、「華麗」というカテゴリからの私のお気に入りの質問です。 テストが互いに矛盾する場合：

-TKは十分に開発されていません。

-TKは矛盾しています。

ここで、テストに「ありがとう」と言って、TKの開発に戻る必要があります。



TDDは時間の無駄です。 最初にコードを記述してから、テストします。 品質に影響を与えない場合でも、不自然な開発順序である「背中合わせ」歩行は、間違いなく「ブレーキ」を引き起こします。



論理的です。 多くの人がそうします。 コードを書きましょう。 書きます。 CVS / SVNでコミットしましょう。 それで何？ 私たちは仕事をしましたか？ 「なんてラッキー」みたい？ 乗る/乗らない？ それは可能です。 それから彼らは「あなたをベッドから持ち上げる」と「ここに何を書いているの？」と尋ねます。



結局のところ、コードを記述して別の方法でテストすることができます。 そして、どのように確認しますか？ ダムピアス？

そして、「ピアス」のために20ステップを踏む必要がありますか？ そして、100なら？ 「データなし」の場合 そして、「下請け業者の準備ができていない」場合はどうなりますか？ 少なくともデバッグのために「テストを書く」のは簡単ではありませんか？ 発明された「頭の外」の出入り。 私の意見では、簡単です。 そして、テストがすでに記述され、デバッグに使用されている場合、このテストを「ナイトビルド」に含めないでください。







TDDは、開発者を屈辱的な立場に置く方法です。 「打たれた無敗は幸運です。」 プログラマーは、果たされていないタスクの永続的な状態で「罪悪感から」働いています。



それどころか、プログラマーは常に「参照ポイント」を持っています。 ここでテストを書きました。 彼は通りません。 ここで機能を実装しました。 テストに合格し始めました。

私はすべてをCVS / SVNにコミットしました。 私は仕事をし、「私は平和に眠ることができます。」



TDD-プログラマーは常に逆問題を解決していると感じていますか？ または、開発者は問題の答えに対するソリューションをカスタマイズするドッペルゲンガーですか？



そして、プログラマーは常に逆問題を解決します。 まあ、または「真空で球形の馬を作りなさい」。 プログラマーはd-oneではなく、すべてを予見できない普通の人です。 しかし、その後、彼が提供したものは動作することが保証されています。 他の人がいます。 しかし、彼らは天才ですが、彼らは少数です。



TDD-見栄えのよいガラスを通しての開発。 エラーがないことを保証するものではないことをテストしました。 テストの質の責任者は誰ですか？



完全なエラーフリー性の保証はなく、開発者が技術仕様を正しく理解し、理解したとおりに実装したという保証のみがあります。



TDDは馬の前のカートです。 馬は絶えず「後部バンパーに」顔を突っ込んでおり、彼の前には何も見えません。 システムアーキテクチャのレベルで機能全体を考える前に、地平線までの距離にある機能について考えることについては、どうしたらいいのでしょうか？



ここでも、「最も科学的な議論」に戻りましょう。 カートとは何か、馬とは何かという用語を定義します。 そして、ウィキペディアで私を脅さないでください（そうでないものをどうやってテストできますか）？



これは正しいでしょう：

-「馬」はTKです。

-「カート」はコードです。



そして、テストは何ですか？ テストは、馬をカートに取り付ける「シャフト」です。 TKのプロセス全体は幸運であり、テストによってコードが引きずられ、TKへの準拠を確認します。 コードはTKと同じ方向に進みます。 TestFirstはありません！ CodeFirst！ TKファーストがあります。 しかし、単純化された場合。 チェーンは次のようになります。TK->アーキテクチャの概要->テスト->コード、そしてオプションが可能です。



TK->アーキテクチャのスケッチ->テスト->コード->テスト->コード

TK->アーキテクチャのスケッチ->テスト->コード->アーキテクチャ->テスト->コード

TK->アーキテクチャのスケッチ->テスト->コード->アーキテクチャ->テスト->コード-> TK->アーキテクチャ->テスト->コード

...など など



最初：TKとアーキテクチャのスケッチ、次に反復開発が始まります。

そして、特においしいのは、テストを書いたら、考える必要はありませんが、クラスのパフォーマンスをチェックする場所はどこですか？ テストおよび検証用のインフラストラクチャ全体をすでにセットアップしています。 これがTDDで駆動されるという言葉の意味です。







さて、世界には「変態」がいます。 それから、少なくともどのように苦しみを軽減できますか？ 適切なプロセスとは何ですか？



いいえ、表敬者に感謝します。 上記のチェーンについて説明しました。 脳の準備ができている場合、プロセスは自動的に整列します。 次に、問題はツールを選択することです。



さて、今私たちは変態ではなく、適切な開発者です。 馬（短い足の頑固なテストポニー）と震える雌（開発者の考え）を利用する方法は？



だから「思考」について。 開発者と一緒にたむろする必要があります、ビールを飲みます（冗談です）。 説得する。 楽しませる。 彼にあなたを信じさせます。 そして、あなたの考えをあなたのものとみなします（こんにちはカーネギー）。 他に方法はありません。 強制することは不可能です。 良いコードを書くことを強制することは不可能なので。 人にMcConnelの誕生日の本を渡すことができます。 しかし、それ以上ではありません。 管理手段は役に立ちませんが、苦味のみを引き起こします。



使用するツールは次のとおりです。

-DUnit。

-DUnitの改善 。

- コンフルエンス ;

-JIRAの自作アナログ; 当時、JIRAはまだ「チーズ」だったため、私たちはそれを受け入れませんでした。 今-私は思う-彼らは彼女を取るだろう。

- スクリプト作成機 ;

-FishEye（https://www.atlassian.com/software/fisheye/overview）;

-コミット、コード変更の関係を追跡し、特定のタスクに対する特定のコード変更のバインディングを構築できるConfluenceおよびFishEyeの改善。

-UMLとConfluenceの統合。







誰がテストを作成しますか？ そして、テスト作成者の「役割」がプログラミングの知識を暗示していない場合はどうでしょうか？



テストは開発者によって作成されます。 新しい機能に関しては。

またはテスター。 エラーになると。

そしてほとんどの場合、テスターはエラーを書き、すぐにテストを書きます。

ちなみに、TKとエラーは基本的にお互いに違いはありません。 「責任の範囲」のみ。

「そして、テスト作成者の「役割」がプログラミングの知識を暗示していない場合」-BDDまたはFit-tablesでは、まだ「振る」ことはありませんが、取り組んでいます。



TDDは「すべて」ですか、それともこの手法の限界を認識していますか？



「コードの中ではなく、頭の中にあります。」 制限はありません。 適用することに抵抗があります。



TDDはすべてのシステムに適用されますか？ 「特別なケース」または「その他のアプローチ」はありますか？



「特別なケース」はありません。 開発者は、「平和に眠り」、あまり考えずに、神経を保ちたいという願望があります。







TDDから捨てることができるもの、持ち込むことができるものがあります。 しかし、全体として、TDDは残り、パニックが発生しないことを保証します。 パニック駆動型開発は除外されます。



何がTDDにあなたをもたらしますか？



必要です。 システムの複雑さが増すにつれて、「私たちは1つのことをしている」、「もう1つは落ちている」ことに気付きました。 その後、テストは必要なコンポーネントになりました。 私たちは彼らに進化的に来ましたが、遅かれ早かれ誰もがこれに来ます。 また、進化的にTDDに切り替えました。 突然それが判明した。 そのテストは便利なだけでなく、便利でもあります。 インフラストラクチャを毎回設定する必要はありません。 テストを作成し、デバッグ環境の準備ができたら、このテストを少なくとも100万回実行します。 だから誰がすでに「感じた」-TDDへようこそ。



TDDよりも優れていると思いますか？



BDD Delphiの世界には、これを実行して推進する人々がいます。 ローマン・ヤンコフスキーはこれに取り組んでいます。 よく、フィットテーブル。 開発したいという願望がある場合は、自分で多くのことを達成できます。 または、半ヒント、大ざっぱな記事、ウィキペディア（最後の手段として）を使用します。 しかし、今日は本当に効果的なプロセスについて話しました。 私はブログに詳細を書いていますが、聴衆とのコミュニケーションは（読者を超えて）TDDの価値を理解することが主な問題であることを証明しています。 今日、これについて話そうとしました。



質問のいくつかが「トローリング」のように聞こえたということはありませんか？



人生では、TDDが生産プロセスに導入されたとき、これは起こりませんでした。 通常の反応。