テストの自動化とテスト駆動開発

Slide 1

Slide 1 text

Slide 8

Slide 8 text

アジャイルなソフトウェア開発とはアジャイルソフトウェア開発宣言私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。アジャイル宣言の背後にある原則私たちは以下の原則に従う: • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 • 動くソフトウェアこそが進捗の最も重要な尺度です。 • アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 • シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。アジャイルソフトウェア開発宣言(2001年) http://agilemanifesto.org/iso/ja/

Slide 22

Slide 22 text

アジャイルの場合アジャイルソフトウェア開発宣言私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。アジャイル宣言の背後にある原則私たちは以下の原則に従う: • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 • 動くソフトウェアこそが進捗の最も重要な尺度です。 • アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 • シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。アジャイルソフトウェア開発宣言(2001年) http://agilemanifesto.org/iso/ja/

Slide 87

Slide 87 text

巷間の感想初TDDの感想 •レッド、グリーン、リファクタリングの黄金の回転は非常に心地がよく、着実に前にすすんでいることを実感できました。 •ふと気づくと動作確認をしていないことに驚きました。作成した関数の戻り値をprint文で出力したり、デバッガを立ち上げて変数の状況を確認してみたり。 •リファクタリングを行って大きくコードを変えても、テストコードが通っている＝仕様を満たせている、という安心感がありました。初ペアプロの感想 •コーディング中の選択ひとつひとつをペアの方と議論して進められるため、自然と質が上がると思います。 •トラブル対応などで一刻も早く対応せねばならず、冷や汗を書きながら震える手でコーディングせねばならない状況においてもペアプロは有効ではないでしょうか。 •他人のコーディングをライブで見ることは気づきの宝庫です。 •メリットも多いけど、業務で毎日ペアプロやるのはしんどそう。週1でペアプロデーを設けるくらいがちょうどいいかも。 TDDBC Tokyo 1.7 for PHP お題1実践記 https://www.karakaram.com/tddbc-tokyo-17/#feedback-tdd 「テストをしながら設計出来る」「テストコードがドキュメントになる」そんな魔法のような売り文句のTDDが魔法でないことを教えてくれる、まさに魔法のようなセミナーでした！！ CodeZine Academy テスト駆動開発実践講座参加者アンケートより「TDDは分析技法であり、設計技法であり、実際には開発のすべてのアクティビティを構造化する技法なのだ。(本書より引用)」ということが良くわかった。オンライン記事などで聞きかじってきたテスト駆動開発は、テストファーストの説明がほとんどであった。対して本書ではテストコードを書くことで設計、実装を深めていく様子を再現し、その有効性を示している。良書を読むことができてよかった。テスト駆動の大きなメリットは、・実装がシンプルになる。・過去に書いたコードの質か担保される→精神的に安定する、自信が持てる。ただ、あくまでプログラムを書く方法の1つであって、全てのテストを書けるわけではないことに注意。テスト駆動の実践は個人でできるものなので、まずは一人でやってみたい。因みに本書でも、「テスト駆動をチームメンバー強要すればするほど、広まらない。」と書かれているw (略)テスト駆動開発の真似事をしてみた感想としては、ーーーこの本にも書かれているがーーー着実な前進感が得られて、心の平静が保たれるところが非常に強力なポイントのように思う。書籍『テスト駆動開発』への感想 (2021.3.26参照) https://bookmeter.com/books/12375096

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text