From bb31fef8345dd1d771e3ad5535033e934b1c7501 Mon Sep 17 00:00:00 2001 From: shinsuke-mat Date: Thu, 18 Jul 2024 18:35:41 +0900 Subject: [PATCH] re-order --- lecture-test.md | 185 ++++++++++++++++++++++++------------------------ 1 file changed, 94 insertions(+), 91 deletions(-) diff --git a/lecture-test.md b/lecture-test.md index b7946f9..d238b29 100644 --- a/lecture-test.md +++ b/lecture-test.md @@ -75,13 +75,15 @@ title: SW設計論 #15 ・リファクタリングのためのテスト ・バグ修正のためのテスト +・回帰バグ対策としてのテスト + +・演習 -・良いテスト ・テストを先に書く開発スタイル ・_"Clean code that works"_ +・良いテスト ・テストは証明ではない -・テストはユーザ第1号である ・SWEBOK @@ -395,77 +397,19 @@ Docker Chef, Puppet, Pulumi --- - -# 開発者が知っておくべきトピック集
－テスト編－ -
- -DUMMY - ---- -# 良いテスト -## 良いテストとは？ -バグの検出能力が高い (≒ 網羅率が高い) -読みやすい･保守しやすい ★ - -## 単純であればあるほどよい -分岐`if` `for`を極力使わない -テスト自体のバグを避けるため -繰り返してもOK, DRYでなくても良い -関数化も最低限に - -## 1テストケース＝1シナリオ -仕様や利用方法という側面もある -たくさんのことをしない - ---- -# 良いプログラムとは？ -
再掲
- -## 信頼性･効率性 (実行的側面の良さ) -目的を満たすか？バグがないか？ -計算リソースの無駄がないか？ - -## 可読性･保守性 -読みやすいか？意図を汲み取れるか？ - -## 拡張性 -拡張時の作業は書き換えか？追加か？ - -## テスタビリティ -`main()` vs `main()`+`sub1()`+`sub2()`+`sub3()` - - ---- -# Complex vs Complicated -
再掲
- -
- - -## ![](https://www.gilkisongroup.com/wp-content/uploads/2019/01/Complicated-or-Complex-2-1200x565.png) -https://www.gilkisongroup.com/investing-complicated-or-complex/ - +# 回帰バグ対策としてのテスト +## 回帰バグ +昔のバグが再度現れる現象 ---- -# 良いプログラムと良いテスト -## テストが楽なプログラムを作ろう -うまく分割統治すればするほどテストが楽 -テストが楽なほど実装も楽 - -分割統治されていない何でもできるメソッド -```java -HugeObject doALotOfThings(param1, param2, param3, ...) { -``` -分割統治された単一のことしかできないメソッド -```java -TinyObject doTinyThing(param1) { -``` +プログラム変更時に発生した意図せぬ別の問題 +バグを直したら別のバグが出てくる -## 良いプログラム ≒ テストしやすいプログラム -責務が明確である, 具体的で明確な名前を持つ -副作用がない, 状態を持たない, 決定的である +「レグレッションがおきた」 +「デグレした」 -関数型言語はテストしやすい +## テストは回帰バグの特効薬 +バグ修正時に必ず対応するテストを作る +プログラム変更時に常にテストを回す --- @@ -610,6 +554,13 @@ IF = `bool isSemVer(s)`　仕様 = `EBNF` DUMMY +--- + +# 開発者が知っておくべきトピック集
－テスト編－ +
+ +DUMMY + --- # テストを先に書く開発スタイル ## TDD - Test driven development, テスト駆動開発 @@ -689,6 +640,73 @@ TDD･テストの恩恵を自然に受けられる DUMMY +--- +# 良いテスト +## 良いテストとは？ +バグの検出能力が高い (≒ 網羅率が高い) +読みやすい･保守しやすい ★ + +## 単純であればあるほどよい +分岐`if` `for`を極力使わない +テスト自体のバグを避けるため +繰り返してもOK, DRYでなくても良い +関数化も最低限に + +## 1テストケース＝1シナリオ +仕様や利用方法という側面もある +たくさんのことをしない + +--- +# 良いプログラムとは？ +
再掲
+ +## 信頼性･効率性 (実行的側面の良さ) +目的を満たすか？バグがないか？ +計算リソースの無駄がないか？ + +## 可読性･保守性 +読みやすいか？意図を汲み取れるか？ + +## 拡張性 +拡張時の作業は書き換えか？追加か？ + +## テスタビリティ +`main()` vs `main()`+`sub1()`+`sub2()`+`sub3()` + + +--- +# Complex vs Complicated +
再掲
+ +
+ + +## ![](https://www.gilkisongroup.com/wp-content/uploads/2019/01/Complicated-or-Complex-2-1200x565.png) +https://www.gilkisongroup.com/investing-complicated-or-complex/ + + +--- +# 良いプログラムと良いテスト +## テストが楽なプログラムを作ろう +うまく分割統治すればするほどテストが楽 +テストが楽なほど実装も楽 + +分割統治されていない何でもできるメソッド +```java +HugeObject doALotOfThings(param1, param2, param3, ...) { +``` +分割統治された単一のことしかできないメソッド +```java +TinyObject doTinyThing(param1) { +``` + +## 良いプログラム ≒ テストしやすいプログラム +責務が明確である, 具体的で明確な名前を持つ +副作用がない, 状態を持たない, 決定的である + +関数型言語はテストしやすい + + ---



@@ -708,11 +726,13 @@ DUMMY ## テストは無料ではない 大きなシステムの全テストは1日かかる -経済 - ---- -# テストの経済学と心理学 +## テストの経済学と心理学 +経済的なテストを作る +　- 効率の良さのこと +開発者の心理を考えてテストを作る +　- 開発者がミスしやすそうな部分を考える +　- 開発経験があるほど良いテストを作りやすい --- # プログラムの正しさの証明？ @@ -731,28 +751,11 @@ DUMMY 形式手法と比べるとテストは手軽で安価 ---- -# サボるために頑張る -投資 - --- parametrized test ---- -# 回帰バグ -## 昔のバグが再度現れる現象 -「レグレッションがおきた」 -「デグレした」 - -プログラム変更時に発生した意図せぬ別の問題 -バグを直したら別のバグが出てくる - -## テストは回帰バグの特効薬 -バグ修正時に必ず対応するテストを作る -プログラム変更時に常にテストを回す - --- # テストスメル