テストの実践知識を学べる「Fifty Quick Ideas To Improve Your Tests」

development testing 50quickideas

今月から非公開グループで読書会することになった Fifty Quick Ideas To Improve Your Tests が好印象だったのでメモ。

Fifty Quick Ideas To Improve Your User Tests -- Fifty Quick Ideas Books

テストの概念や技法ではなく、利用者の役に立つソフトウェアを開発するための手段としてテストを活用するための4種類のカテゴリに編成されたノウハウを、具体的な事例と共に紹介している。

  • テストの発想を生み出す(Generating testing ideas)
    • 利用者のためになるテストとは何か、それを導き出すためにはどうすればいいか、どうすれば上手く実施できるか、みたいなことがまとまってる
  • 適切なチェックの設計(Designing good checks)
    • 未読
  • テスト容易性の改善(Improving testability)
    • 未読
  • 大規模なテストスイーツの管理(Managing large test suites)
    • 未読

冒頭の4章くらいしか読んでないけど、専門家の人からしても的を射た内容になっている。

それぞれの章は10分あれば読めるくらいの分量だし、特につながりもないので気になる章をつまみ読みできるのもよい。

出版されたのは2015年と少し古いけど、普遍的な内容を扱ってるので2021年でも十分に読む価値がある。

Fifty Quick Ideasではユーザーストーリーやふりかえりの本も紹介されており、たぶんそれらもいい感じの内容なんじゃないかと思う。

LeanPubではePUB/PDF/Kindle/オンラインビューアそれぞれの形態で販売されてる。 個人的にはPDFやオンラインビューアがあるのがとても好印象。

Javaプロジェクトのビルドツール、Gradleにするか、Mavenにするか

development java

最近になって突然理解した。 選択するときは、柔軟性とAPIの安定性のトレードオフを考えないといけない。

総合評価

「成果物のビルド」を改善する意思と時間の有無に応じて選択するとよさそう。 消極的な姿勢なら Maven を、前向きな姿勢なら Gradle を採用すればいいだろう。

  • ビルドスクリプトに高度な柔軟性が求められるなら、まずは構成を工夫して簡素化できないか試みた方がよい
    • どうしても簡素化できないなら柔軟性に優れた Gradle を採用するしかない
  • プロジェクトの積極的な開発は1年未満で終了する(消極的な維持、保守は継続する場合)
    • APIの安定性を重視して、Maven を採用する(維持や保守のためにビルドツールをメンテナンスするのはムダである)
  • プロジェクトの積極的な開発は1年以上継続する
    • 「成果物のビルド」を開発プロセスの一部として重視しており、改善し続ける意思があるなら Gradle を採用する
    • 「成果物のビルド」よりアプリケーション本体の拡充を中心とするなら Maven を採用する

柔軟性

Gradle は Groovy/Kotlin でスクリプトを記述できるし、プラグインプロジェクトをbuildSrcで管理できるため、柔軟性がとても高い。 それに比べて Maven のプラグインモデルはややこしいので、解決したい問題の重みとプラグインを自作する大変さが割に合わないことが多いと思う。

問題の規模 Gradle Maven 結論
公開プラグインで解決できる ○ ○ 同等
ビルド定義ファイルを工夫すれば解決できる ○ △ Gradle
プラグインを自作すれば解決できる ○ △ Gradle

APIの安定性

基本的にメジャーバージョンアップでは一部のAPIの互換性が損なわれる、あるいは、排除される場合がある。 そうするとビルドが壊れてしまうので、プロジェクトとしては追加の仕事が増えてしまうことになる。

リリースノートからメジャーバージョンアップの期日を取り出して並べてみるとこうなる。 Gradle は更新間隔が短く Maven は長い。 更新間隔が長いということは、APIの安定する期間が長いということだ。

Maven

バージョン 期日 前回のリリースからの期間
1.0 2004-07-13
2.0 2005-10-20 1年3ヶ月
3.0 2010-10-08 5年
3.1.0 2013-07-15 2年9ヶ月
3.6.3 2019-11-25 6年4ヶ月

Gradle

バージョン 期日 前回のリリースからの期間
v1.0 2012-06-12
v2.0 2014-07-01 2年1ヶ月
v3.0 2016-08-15 2年1ヶ月
v4.0 2017-06-14 10ヶ月
v5.0 2018-11-26 1年5ヶ月
v6.0 2019-11-08 1年
v6.8.2 2021-02-05 1年3ヶ月

第2回 The Software Architect Elevator 読書会@リモートのログ

development javaeestudy

learning.oreilly.com

javaee-study.connpass.com

引き続き Discord によるオンライン開催。

今回は 04. Enterprise Architect or Architect in the Enterprise? から。

javaee-study.connpass.com

次回は3/13(土)、9. Architecture Is Selling Options から。

トピック

  • トレンドに逆張りして東京へ引っ越した
    • 食洗機の稼働が遅れてる（自損）
    • popIn Aladdinをお試し中
  • ミキサーが届いたので調整中
  • Clubhouse の利用体験を改善できそうなデバイスを模索中
  • 腰痛で日常生活が崩壊した（気温の変動が激しすぎ）
  • 仕事の余暇にGoとかTypeScriptとかを試したりしてる
  • ワンダビジョンはいいぞ

ディスカッション

4. Enterprise Architect or Architect in the Enterprise?

5. An Architect Stands on Three Legs

6. Making Decisions

7. Question Everything

Part II. Architecture

8. Is This Architecture?

参考情報

第1回 The Software Architect Elevator 読書会@リモートのログ

development javaeestudy

learning.oreilly.com

learning.oreilly.com

javaee-study.connpass.com

引き続き Discord によるオンライン開催。

今回は Chaos Engineering の補習をしてから The Software Architect Elevator に進む。

次回は 04. Enterprise Architect or Architect in the Enterprise? から。

javaee-study.connpass.com

トピック

ディスカッション

20. The Case for Security Chaos Engineering

  • GitHub - Optum/ChaoSlingr: ChaoSlingr: Introducing Security into Chaos Testing
    • 企業が主体となって公開する本業と異なる目的のツールはアーカイブされがち（主観）
  • パープルチームエクササイズってなんだろう
    • 攻撃（レッド）と防御（ブルー）だけではゲームになってしまうため、それぞれの内容を混合したチーム（パープル）を使うみたいな
  • 普通のカオスエンジニアリングの話のような
    • セキュリティの取り組みは基本的に未知への対応なので同じような話になりがち

21. Conculusion

  • 人間が重要だった
  • "Risk Management in a Dynamic Society: A Modelling Problem"
    • 安全性の向上に加え、境界を可視化すること
    • インシデントレビューやレジリエンシーを文脈として普遍の知識とすることは、「根本原因」を探したり、ルールを適用したりするより実用的かつ実践的である
  • 直感に反している事例3つ、もっと掘り下げてよかったと思う
    • 直感的には、システムに冗長性を追加すると安全性が高まることは理にかなっている。残念ながら、経験からこの直感は正しくないことが分かっている
    • 直感的には、システムから複雑さを取り除くことでシステムがより安全になることは理にかなっている。残念ながら、経験からこの直感は正しくないことが分かっている。
    • 直感的には、システムを効率的に運用することで安全性が高まることは理にかなっている。残念ながら、経験からこの直感は正しくないことが分かっている

完走した感想

第一部 アーキテクト

  • 頻出フレーズ corporate IT
  • 「ゾンビの中で生きたいと思わないように、システムを（ブレードランナー的な意味で）「解任」させることも含まれている」
    • どういう意味だろう
    • ja.wikipedia.org/wiki/ブレードランナー
      • 脱走レプリカント達を判別し見つけ出した上で「解任（抹殺）」する任務を負うのが、警察の専任捜査官「ブレードランナー」であった。

  • 頻出フレーズ First Derivative

    • どういう意味だろう
    • 一次導関数 ではないと思われる
    • 第一級の派生物（証券の派生商品的な）じゃないかなぁ

  • アーキテクトっていう職種はある？あるとしたら仕事の切り分けってどうしてる？

    • まさに「浮世離れ」した人でレビューとか相談相手とかしてる
    • プラットフォームに近い領域から全体を俯瞰する仕事をしてる
    • SIer 的な組織で自分の名刺にアーキテクトって書いてた
      • PM と具体的な作業をする人たちの成果をつなぐための仕事をしてた
        • 設計書のフォーマットを用意する
        • 設計書の記述を実装に変換するためのガイド
    • いわゆる「ソリューションアーキテクト」は「技術営業」相当
    • 公開されてる job description

  • 人と人とをつなぐ仕事と、システムとシステムをつなぐ仕事があるような気がしてきた

  • わたしたちにとって典型的なアーキテクト象は「マーティン・ファウラー」

    • アナリシスパターンの分かりにくさが印象的
    • 最近は技術要素の細分化が激しいのでアーキテクトの役割も細分化していっている

01. アーキテクトエレベーター

  • なるほど。ビルのメタファーだったのか

  • どういう人がアーキテクトとして残るんだろう

    • 今の会社（組織）が好きな人は残りそう
      • ビジネスではなくビジネスを実現する仕組みが好きな人、という意味
    • 今の会社（組織）が好きな人にはドラスティックな変更が大変そう

2. Movie-Star Architects

03. Architects Live in the First Derivative

  • first derivative の訳語はどうしよう･･･

  • なんでいきなりアーキテクチャの重要な要素とか言い出してるのか

    • 突然すぎてびっくりする
    • first derivative がビルドツールチェインだという説明をしたいから、その必要性を変更頻度に求めている感じ？
    • 大筋は理解できるけど、文章構成に疑問が残る

  • 相変わらず CTO の仕事とアーキテクトの仕事の区別が分からない

    • CTOは立場、アーキテクトは役割
    • 立場には責任がついてくるけど、役割はそうではない
    • CTO=親分、アーキテクト=鉄砲玉、みたいなイメージ

  • 変更が不要なシステムは現実的に存在しないので、変更は必要だよね、その上で時間とか規模とか考えていくと変更頻度が重要なことは分かるよね、という展開なら分かる

参考情報

2020-12 にキーワード「Software Testing」でヒットした最近の本

development

某読書会で読む機会があると助かるやつ！

www.amazon.com

www.amazon.com

www.amazon.com

www.amazon.com

www.amazon.com

www.amazon.com

www.amazon.com

www.amazon.com

www.amazon.com

第9回 Chaos Engieering 読書会@リモートのログ

development javaeestudy

learning.oreilly.com

javaee-study.connpass.com

引き続き Discord によるオンライン開催。

こちらのリストで次の本を検討してます。

次回は 20. The Case for Security Chaos Engineering から。読書会は最終回です。

javaee-study.connpass.com

同日に The Software Architect Elevator 読書会が始まります。

learning.oreilly.com

javaee-study.connpass.com

トピック

  • オンライン忘年会は工夫が必要
  • TENETわからん（10回以上観てる）
  • KubeCon参加したけど時間帯が厳しかった
  • M1 MacBook Air を待ち焦がれてる人、もう手元にある人、それぞれ
  • LIVE DEV DAYよかった
  • VTuberのゲーム実況動画を観るようになった

ディスカッション

17. Let’s Get Cyber-Physical

  • もはやいろんなシステムが分散システムと同じような複雑さに取り組むようになっている

    • 技術が進化すると今までの信頼性モデルが破綻する、というのはなんか逆説的

  • ソフトウェアでプローブ効果が発生したことってある？

  • 機械工学出身のエンジニアとして、カオスエンジニアリングの位置づけを解釈してみた、みたいな感じ

    • ソフトウェアの世界では抽象度を高くするように発展してる気がするので逆ですね

18. HOP Meets Chaos Engineering

19. Chaos Engineering on a Database

  • TiDBの開発を通じての事例
  • 正直期待外れだった
    • RDBを利用する立場での取り組みならよかったのに

参考情報

testcontainers のための Docker への接続情報を環境変数で指定する

development java docker

前提

課題

解決方法

例

ファイルレイアウトはこういう感じになります。

./build.gradle
./settings.gradle
./src/main/java/xxxx
./src/test/java/xxxx
./.env

.env ファイルの内容は次のような感じです。

$ cat .env
DOCKER_CERT_PATH=/path/to/docker/certs
DOCKER_TLS_VERIFY=1
DOCKER_HOST=tcp://dockerhost:2376

最終的な build.gradle は次のような感じになります。

plugins {
    id 'java'
    id 'co.uzzu.dotenv.gradle' version '1.1.0' // プラグインの追加
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = JavaVersion.VERSION_11

repositories {
    mavenCentral()
}

dependencies {
    testImplementation('org.junit.jupiter:junit-jupiter-api:5.3.1')
    testRuntimeOnly('org.junit.jupiter:junit-jupiter-engine:5.3.1')
    testImplementation('org.testcontainers:junit-jupiter:1.14.3')
    testImplementation('org.testcontainers:postgresql:1.14.3')
}

test {
    useJUnitPlatform()
    // environment で指定した環境変数だけになるので、System.getenv() も指定しないとおかしなことになる
    environment = System.getenv() + [
        'DOCKER_HOST'      : env.fetch('DOCKER_HOST', 'unix:///var/run/docker.sock'),
        'DOCKER_TLS_VERIFY': env.fetch('DOCKER_TLS_VERIFY', ''),
        'DOCKER_CERT_PATH' : env.fetch('DOCKER_CERT_PATH', ''),
    ]
}