TDDサイクルは戻ることも大事

はじめに

本記事はテスト駆動開発 Advent Calendar 2021の1日目の記事です。このアドベントカレンダーはスカスカなので、テスト駆動開発経験談などをエントリーしてもらえると嬉しいです!

qiita.com

目次

  • はじめに
  • 目次
  • 本記事で伝えたいこと
  • 今回のお題
  • 新しいテストケースを考えて対応する
    • サイクル2周目の「3.そのテストを実行して失敗させる」
    • サイクル2周目の「5. 2で書いたテストを成功させる」
    • サイクル2周目の「6. テストが通るままでリファクタリングを行う」
      • 関数を呼び出す形に変更する
      • テストケースを1つ削除する
      • メソッドをインライン化する
  • おわりに

本記事で伝えたいこと

TDDをやっている皆さんは、下記のサイクルをご存知の方が多いと思います。

f:id:nihonbuson:20211201110545p:plain
見てわかるテスト駆動開発 / TDD Live and Workshop 2019 Spring - Speaker Deckより引用

この中の「4. 目的のコードを書く」がうまくいかない時に、「3.そのテストを実行して失敗させる」よりも前まで戻ることがよくあるよ、というお話です。

続きを読む

JaSST Review'21で講演依頼をしたきっかけ 〜ソニックガーデン/ベリサーブ編〜 #jasstreview

10月22日にJaSST Review'21(ソフトウェアレビューシンポジウム)を開催します!

www.jasst.jp

本記事では、JaSST Review'21でなぜ「ビジネスの成長に合わせてソフトウェアを進化させ続ける秘訣」という講演を依頼したのか、その経緯を紹介します。

今回のイベント全体の主旨については、以前書いた記事をご覧ください。

nihonbuson.hatenadiary.jp

目次

今回のJaSST Reviewのテーマ

今回のテーマは「価値を実現するためにレビューができること」です。

前回までのJaSST Reviewでは、「どういうアプローチでレビューしていこう?」という話が多かったです。JaSST Reviewに参加して持ち帰った結果、実のあるレビューに変わっていった現場もあったと思います。

しかし、一見実のあるレビューができたとしても、こんな風になってしまう経験はありませんでしょうか?(JaSST Review'21のページから抜粋)

「こうして欲しい」とお客様に言われた通り作ったが、「欲しいのはこんなものではなかった」と言われてしまった。

つまり、そもそも作ろうとしているものが、顧客が本当に必要だったものに合っていなかったという経験です。

これをレビューで解決できないか模索したいというのが今回のテーマです。

講演依頼をするきっかけ

今回のテーマにするにあたり、プロダクトオーナー(PO)と開発者が「顧客が本当に必要だったもの」について話していたなと感じたイベントとして、「Veriserve - WebQA FunNight!! #01」を思い出しました。

veriserve.connpass.com

このイベントの中で、今回のJaSST Reviewで登壇する、POの松木さんと開発者の遠藤さんがこんな会話をしていました。

f:id:nihonbuson:20211012162159p:plain
Veriserve - WebQA FunNight!! #01聴講報告記事より抜粋

この内容で興味深いのは、「○○ができるようにしたい」と要望を伝えるPO(松木さん)に対して、「それは大変になるから止めよう」と伝える開発者(遠藤さん)という構図です。

一般的に、POは「プロダクトの価値を最⼤化することの結果に責任を持つ。」*1はずです。

しかしお二人の会話からは、そんなロールの関係性を超えて、「顧客が本当に必要だったもの(プロダクトの価値)」について一緒に考えているように感じました。

講演依頼の内容

上記のイベントのように、「顧客が本当に必要だったもの」について常日頃話しているようなので、そのことについて是非話してほしいと講演を依頼しました。

また、我々からの依頼時に、「1人ではなく、2人一緒の登壇でも良いですか?」とリクエストされ、是非その方向でお願いすることにしました。というのも、上記のイベントでの2人の掛け合いが印象深く、かつリアリティのある内容だったと記憶しています。

JaSST Reviewでは、理論的な話よりも、イキイキとした事例を求めています。というのも、レビューはまだ体系だった形にできていないと思っており、まだまだ事例を集める段階だと思っているからです。

そんな中、遠藤さんと松木さんによる2人の登壇はおそらくイキイキとした事例を我々に聞かせてくれるのではないかと期待しています!

おわりに

今回は、JaSST Review'21で「ビジネスの成長に合わせてソフトウェアを進化させ続ける秘訣」の講演を依頼する経緯と依頼内容について書きました。

なお現在、JaSST Review'21では聴講者を募集しております。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp

JaSST Review'21で講演依頼をしたきっかけ 〜三越伊勢丹ホールディングス/IM Digital Lab編〜 #jasstreview

10月22日にJaSST Review'21(ソフトウェアレビューシンポジウム)を開催します!

www.jasst.jp

本記事では、JaSST Review'21でなぜ「三越伊勢丹におけるデジタルサービスのつくりかた(仮)」という講演を依頼したのか、その経緯を紹介します。

今回のイベント全体の主旨については、以前書いた記事をご覧ください。

nihonbuson.hatenadiary.jp

目次

今回のJaSST Reviewのテーマ

今回のテーマは「価値を実現するためにレビューができること」です。

前回までのJaSST Reviewでは、「どういうアプローチでレビューしていこう?」という話が多かったです。JaSST Reviewに参加して持ち帰った結果、実のあるレビューに変わっていった現場もあったと思います。

しかし、一見実のあるレビューができたとしても、こんな風になってしまう経験はありませんでしょうか?(JaSST Review'21のページから抜粋)

「こうして欲しい」とお客様に言われた通り作ったが、「欲しいのはこんなものではなかった」と言われてしまった。

つまり、そもそも作ろうとしているものが、顧客が本当に必要だったものに合っていなかったという経験です。

これをレビューで解決できないか模索したいというのが今回のテーマです。

講演依頼をするきっかけ

上記の内容でテーマは決まったときに、思い浮かんだのがDevelopers SummitでのIM Digital Lab様の発表でした。

event.shoeisha.jp

この発表の資料も公開されているのですが、その中でも特に注目したスライドが2枚あります。

f:id:nihonbuson:20211005093759p:plain
発表資料「三越伊勢丹が目指すNew Normalの購買スタイル」より抜粋

f:id:nihonbuson:20211005100924p:plain
発表資料「三越伊勢丹が目指すNew Normalの購買スタイル」より抜粋

この2枚のスライドで特に注目した点は下記の部分。

  • 三越伊勢丹という大企業にもかかわらず、初期開発が3ヶ月という短い期間で新しいアプリを作成した点
  • 「その機能じゃ足らない」問題が発生し、それに対しての解決しようとしている点

特に「その機能じゃ足らない」問題は今回のJaSST Reviewで気にしている部分「そもそも作ろうとしているものが、顧客が本当に必要だったものに合っていなかったという経験」にフィットするのではないかと思い、講演を依頼することにしました。

講演依頼の内容

この「その機能じゃ足らない」問題は、初期開発をしている時にはよく発生すると思っています。

上記の発表資料の他ページを見ると、うまく要件整理をして、優先順位を決め、調整していったことが書かれています。ただ、どのように「うまく」行い、どのように「調整」を行っていったのでしょうか?

これらの内容は、実装を始める前に「価値」を見つめ直し、各関係者とMTGを行い、内容に対してレビューしながら進めていったはずです。「そのときに頭の中で考えていったことを聞きたい!」と講演を依頼しました。

現在、講演内容案をいただいていますが、上記の依頼内容にマッチした素晴らしい講演が期待できるものになっていました!

おわりに

今回は、JaSST Review'21で「三越伊勢丹におけるデジタルサービスのつくりかた(仮)」の講演を依頼する経緯と依頼内容について書きました。

なお現在、JaSST Review'21では聴講者を募集しております。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp

JaSST Review'21の見どころ 〜価値を実現するためのレビューとは何か〜 #jasstreview

JaSST Reviewを今年も開催します。4回目の開催です!

本記事では今回の見どころをざっと紹介していきます。読んだ上で興味がある発表がありましたら、ぜひイベントに参加登録をお願いします!

www.jasst.jp

目次

JaSST Reviewとは何か

JaSSTとはソフトウェアテストシンポジウム(JaSST)のことで、2003年から全国各地で開催されているテストのイベントです。全国で年間10回以上開催されています。

そしてJaSST ReviewはJaSSTの一つで、ソフトウェアレビューに特化したイベントです。

詳しくは以前書いた下記記事を参照してください。

nihonbuson.hatenadiary.jp

今回のJaSST Reviewのテーマ

今回のテーマは「価値を実現するためにレビューができること」です。

以下、JaSST Review'21のページから抜粋。

実際に現場ではこんな事態が起こることがあります。

・「こうして欲しい」とお客様に言われた通り作ったが、「欲しいのはこんなものではなかった」と言われてしまった。

・利用者の要望に応えて実装したが、システム運用が大変な手間になってしまった。

結果として、いくら頑張って開発していても、開発リソースなどの投資に対しての(経済的・非経済的)効果が得られず終わってしまうこともあるのが現実ではないでしょうか。

これらの課題に対して、レビューでできることは何でしょうか?

うまくいっているチームではどんなレビューがされているのでしょうか?

うまくいっている開発チームではどのようなレビューがされているのか、 うまくいっている理由は何なのかについて、今年のシンポジウムで掘り下げていきます。

今回、掘り下げていきたいものを「顧客が本当に必要だったもの」の絵を例にして話したいと思います。

顧客が本当に必要だったもの

皆さんは「顧客が本当に必要だったもの」という絵をご存知でしょうか?

f:id:nihonbuson:20210909105032p:plain
引用元:プロジェクトの姿~顧客が本当に必要だったもの

これは、システム開発プロジェクトの姿を風刺した絵です。本当に必要だったものは、開発に関わる人だけでなく、顧客自身も気づいていないかもしれないことを表しています。

この絵を前提として、レビューでできることとはどんなことでしょうか?

まず、設計書作成者が以下の認識を持っていたとします。

f:id:nihonbuson:20210909105807p:plain
設計書作成者の認識

それに対して、レビュアーは欠陥の指摘ができるかもしれません。

f:id:nihonbuson:20210909105859p:plain
欠陥の指摘

もしくはプロジェクトリーダーとの認識のズレを指摘できるかもしれません。

f:id:nihonbuson:20210909105952p:plain
プロジェクトリーダーとの認識ズレの指摘

もしかしたら、顧客の認識のズレを指摘できるかもしれません。

f:id:nihonbuson:20210909110058p:plain
顧客との認識ズレの指摘

ただし、顧客が持っていた認識が必ずしも正しいとは限りません。本当に必要だったものを伝えられれば、必要最低限の実装で満足いくものができたかもしれません。

f:id:nihonbuson:20210909110240p:plain
本当に必要だったものとのズレの指摘

とはいえ、必ずしもレビュアーが全てを認識できているわけではありません。なので、もしかしたら確認する質問をレビュアーが投げかけることで、新たに見えてくるものがあるかもしれません。

f:id:nihonbuson:20210909110352p:plain
認識ズレを確認する質問

今回のJaSST Reviewで掘り下げていきたいところ

今回は、色々な情報がある中で、レビューで「顧客が本当に必要だったもの(=価値)」を見極める、もしくはそこに立ち返るにはどうすれば良いかを掘り下げていきたいと思っています。

今回講演をお願いした2組(4名)は、普段の業務の中で「顧客が本当に必要だったもの」を見極めたり立ち返ったりしている方々だと思っています。(講演を依頼した詳しい経緯は別記事で紹介する予定です)

追記:講演依頼の経緯を記事にしました!

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

イベントでは、普段どのようなきっかけで、価値に立ち返ったりできるのかお話が聞けることを期待しています。

おわりに

今回のJaSST Reviewでは上記のようなことを深く考えていきたいと思います。

本イベントに参加して、普段の皆さんのレビュー活動(レビューミーティングだけでなく、同僚へのフィードバックなども)がさらに有意義になればと思います。

現在、参加登録募集中です。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp

テスト駆動開発の題材を目的別で紹介する

はじめに

本記事はテスト駆動開発 Advent Calendar 2021の3日目の記事です。8月に書いた記事であり、新作ではありませんが、アドベントカレンダーがスカスカなので穴埋めします。

アドベントカレンダーへのご参加をお待ちしております!

qiita.com

この記事を書いた目的、読んでもらいたい対象

書籍『テスト駆動開発』には下記のように書かれています。

テスト駆動開発の良さ、強みは手を動かせば分かります。

結果ではなく過程に本質があります。

テスト駆動開発とは練習によって獲得できる技術です。

ですが、その練習の題材として何があるのか、知らない人も多いかもしれません。

そこで本記事では、テスト駆動開発(以下、TDD)の練習題材になりそうなものを紹介していきます。また、私なりの題材のポイントも合わせて紹介します。

FizzBuzzの次に何をしよう…?」と悩んでいる人に参考にしてもらえればと思います。

目次

題材を紹介する前に 〜題材の使い方〜

TDDで題材を選ぶポイントは以下の2つがあります。

TDDを練習するには、この2つのバランスを考えた方が良いです。

例えば、新しく学ぶプログラミング言語のTDDを練習しようと思ったら、簡単な題材を選びましょう。

一方、ある程度業務でも使っているプログラミング言語のTDDを練習しようと思ったら、少し応用の題材でも良いかもしれません。

基本問題

ここからは、題材になるようなものをどんどん紹介していきます。

まずは基本問題です。新しいプログラミング言語を使ったり、初めてTDDを練習してみる時は、この基本問題に書いている題材から始めると良いでしょう。


題材1. FizzBuzz

みんな大好きFizzBuzzです。

ja.wikipedia.org

この題材を用いて、t_wadaさんがライブコーディングしている講演が既にYoutubeに上がってます。この動画を見ながら、写経してみるのも良いかもしれません。

www.youtube.com


題材2. ローマ数字変換

ローマ数字を数値に変換するプログラムです。

github.com

例えば、下記のようになります。

◆入力値
MCMXLIV
◆出力値
1944

毎回FizzBuzzばかりで飽きた人向けです。

ただし、単純作業が多く発生するため、途中で飽きる可能性があります。


題材3. ボウリング

ボウリングの点数を算出するプログラムです。

codingdojo.org

例えば、下記のようになります。

◆入力値
X 12 9/ 12
※「X」がストライク、「/」がスペア
◆出力値
30

最初は単純な足し算をやった後に、ストライクやスペアの計算についての仕様を追加していく形になるでしょう。


題材4. 格子点

x座標とy座標からなる格子点についての問題です。

devtesting.jp

入試数学のように導かれるような順番で出題されているので、ステップバイステップでTDDを練習することができます。

この題材を用いた、いのうえさんととーますさんのペアプロ動画が既にYoutubeに上がってます。この動画も参考にしてください。

www.youtube.com

設計まで踏み込む問題

基本問題から少し発展した問題です。言語、TDDに少し慣れてきた人が解いてみると良いでしょう。


題材5. 火星探索機

初期位置(x,y)とステージの広さを定義した後、「90°右回転」「90°左回転」「前進」「後進」の指示を元に、現在位置(x',y')を求める問題です。「題材4. 格子点」の応用のような位置付けです。

danilsuits.github.io

火星は球体なので、ステージの広さが(5,5)の広さの時、初期位置(1,1)の北向きで90°左回転して前進すると、現在位置は(5,1)になるのがポイントです。

例えば、下記のようになります。

◆入力値
初期位置(1,3)、ステージの広さ(5,5)、北向き
「90°左回転」「前進」「90°右回転」「前進」
◆出力値
現在位置(5,4)、北向き

題材6. ポーカー

ポーカーの手札の役判定などを行う問題。

devtesting.jp

上記のTDDBC Sendaiの出題がステップバイステップで分かりやすいので、入出力例についてはそちらを見てください。

題材にも馴染みがあるので、取り組みやすいかもしれません。

ボトムアップで取り組む問題

一定のルールに基づいているので、まずは小さい範囲で考えて、だんだんとその範囲を広げて解いていく形式の問題です。


題材7. ラングトンのアリ

正方形が敷き詰められた地面にアリがいて、下記のルールに従ってアリが進む問題です。

  • 現在位置が白マスだったら黒マスに変更して右に進む
  • 現在位置が黒マスだったら白マスに変更して左に進む

ja.wikipedia.org

シンプルなルールですが、下記画像のように面白い動きになります。

f:id:nihonbuson:20210510171430g:plain
Wikipediaより

プログラム入出力例は下記のようになります。

◆入力値
ステージの広さ(3,3)、初期位置(2,2)
◆出力値(※「-」が白マス、「*」が黒マス)
0
---
-a-
---

1
-a-
-*-
---

2
-*a
-*-
---

3
-**
-*a
---

4
-**
-a*
---

5
-**
--*
-a-

題材8. ライフゲーム

正方形に敷き詰めた地面に対して、条件によってセルが生きたり死んだりします。 条件は下記の通りです。ここでいう「隣接するセル」とは、自身のセルの上下左右斜めの8つが対象です。

  • 死んでいるセルに隣接する生きたセルがちょうど3つあれば、次の世代が誕生する。(誕生)
  • 生きているセルに隣接する生きたセルが2つか3つならば、次の世代でも生存する。(生存)
  • 生きているセルに隣接する生きたセルが1つ以下ならば、過疎により死滅する。(過疎)
  • 生きているセルに隣接する生きたセルが4つ以上ならば、過密により死滅する。(過密)

ja.wikipedia.org

この題材も面白い動きになります。

f:id:nihonbuson:20210510173158g:plain
Wikipedia(英語版)より

プログラム入出力例は下記のようになります。

◆入力値
ステージの広さ(5,5)、初期生存セル(2,3)(3,3)(4,3)
◆出力値(※「-」が死滅セル、「*」が生存セル)
0
-----
-----
-***-
-----
-----

1
-----
--*--
--*--
--*--
-----

2
-----
-----
-***-
-----
-----

トップダウンで取り組む問題

途中で仕様が追加されていく問題です。問題を進めるに従ってコードが変化していくはずです。


題材9. Potter

ルールに従って、同じシリーズまとめ買いによる値段の割引が行われる時、その最安値を求める問題です。

codingdojo.org

ルールは下記の通りです。

  • 1冊1000円
  • 同じシリーズの別の巻を2冊買うと、それぞれ5%引き
  • 同じシリーズの別の巻を3冊買うと、それぞれ10%引き
  • 同じシリーズの別の巻を4冊買うと、それぞれ15%引き
  • 同じシリーズの別の巻を5冊買うと、それぞれ20%引き

例えば、下記のようになります。

◆入力値
第1巻を1冊、第2巻を1冊
◆出力値
(1000*2)*0.95=1900円

◆入力値
第1巻を2冊
◆出力値
1000 * 2 = 2000円
※同じ巻なので割引なし

◆入力値
第1巻を2冊、第2巻を1冊
◆出力値
(1000*2)*0.95+1000=2900円

◆入力値
第1巻を2冊、第2巻を1冊、第3巻を1冊
◆出力値
(1000*2)*0.95+(1000*2)*0.95=3800円
(1000*3)*0.9+1000=3700円
※(第1巻+第2巻)の5%引き+(第1巻+第3巻)の5%引きのパターンと、
(第1巻+第2巻+第3巻)の10%引き+第1巻のパターンが存在する

題材10.LCD表示

数値を与えられると、それに対するLCD表示(デジタル表示)を求める問題です。

codingdojo.org

例えば、下記のようになります。

◆入力値
2
◆出力値
 _ 
 _|
|_

問題が進むと、途中で仕様変更が発生し…というのがミソ。ネタバレ防止のために、ここには記載しません。


題材11.自動販売

自動販売機の動きをプログラミングする問題です。

題材: プログラミングのお題: 自動販売機 (設計進化重視バージョン) · GitHub

仕様が提示されている形式なので、単なるTDDではなく、cucumberなどを用いたATDDで解くのもオススメです。

またこの題材を元に、TODOリストの整理の仕方について説明した発表を以前に行いました。

speakerdeck.com

レガシーコードのリファクタリングの問題

ここからは既存のコード(テストコード無し)に対して、リファクタリングをしていく問題です。


題材12. テニスゲーム

テニスの点数表示を題材とした問題です。詳しくは、リンク先参照。

github.com

同じ仕様に対して3パターンの実装があるので、1つの言語に対してリファクタリングを3回練習できます。

テニスの計算方法を知っていれば、仕様の読み込みを行う必要がなく、すぐに問題に取り組めるので便利な題材です。

ソースにはテストコードが既にありますが、既存のテストコードを消して、レガシーコードのリファクタリングの練習として使うのがオススメです。

先日公開した書籍『テストコードの注入から始めるレガシーコードのリファクタリング』では、この題材のリファクタリング過程を載せて解説しています。

leanpub.com


題材13. GildedRose

仕様もあって面白い問題です。詳しくは、リンク先参照。

github.com

今年のJaSST Tokyoでも題材にして、実際にリファクタリングする様子をライブコーディングしました。

www.jasst.jp

また、先日公開した書籍『テストコードの注入から始めるレガシーコードのリファクタリング』では、この題材のリファクタリング過程を載せて解説しています。

leanpub.com


題材14. trivia

クイズゲームを題材とした問題です。詳しくはリンク先参照。

github.com

この題材をリファクタリングしている動画が既にYoutube上にあったりします。

www.youtube.com

さいごに 〜参考文献など〜

TDDの題材になりそうなものをざっと紹介してみました。

ご自身のプログラミング言語のスキルレベル、TDDのスキルレベルに合わせて、適切な難易度かつ楽しそうな問題を選んで取り組んでみてください!

もしも「他の題材も探したい!」という人は、下記のサイトがオススメです。


TDD Boot Camp(TDDBC)

devtesting.jp

おそらくTDDに関して日本で一番充実しているサイト、コミュニティです。

年に数回、ワークショップ形式のイベントも開催しています。

本文中に紹介した、t_wadaさんのライブコーディング動画や、いのうえさんととーますさんのペアプロ動画はこのコミュニティのイベントによるものです。


All Kata

All Katas

今回紹介した題材の多くが載っているサイトです。

Kataの用途ごとにTopicが分かれているので、行いたい内容を元に題材を探すにも最適です。


Coding Dojo

codingdojo.org

今回紹介した題材の多くが載っているサイトその2です。

All Kataに比べると、目的にあった題材を探すのは少し難しいです。


Cyber Dojo

www.cyber-dojo.org

オンライン上でTDDを練習できるサイトです。

現時点で58種類の問題が用意されています。

ただし一覧になっているので、難易度や目的に沿ったお題なのかは分かりづらいかも。


Philippe Bourgau's XP Coaching Blog - A coding dojo exercises plan towards refactoring legacy code

philippe.bourgau.net

題材集ではないですが、今回のブログを書くにあたって大いに参考にしたサイトです。

題材を区切った種別の仕方(ボトムアップトップダウンなど)は、このサイトを参考にしました。


最後に、書籍『テスト駆動開発』の文章をもう一度載せます。

テスト駆動開発の良さ、強みは手を動かせば分かります。
結果ではなく過程に本質があります。
テスト駆動開発とは練習によって獲得できる技術です。

ぜひ、たくさん練習して、TDDを身に付けてくださいね!

最近更新した翻訳or執筆書籍の紹介

ここ最近、いずれもLeanpub上に公開している3冊の書籍を公開or更新しましたので、その内容をご紹介します。

f:id:nihonbuson:20210804092654p:plain

書籍『A Practical Guide to Testing in DevOps Japanese Edition』の公開

書籍『A Practical Guide to Testing in DevOps』の日本語版を公開しました!

leanpub.com

実装前や実装中でのテストだけでなく、本番環境でのテストについて、数多くの事例を用いて語られています。

書籍内容について詳しくは、先日書いた以下の記事をご覧ください。

nihonbuson.hatenadiary.jp

書籍『Agile Testing Condensed Japanese Edition』第4版の公開&まとめ買い用のオプションを追加

8月1日に書籍『Agile Testing Condensed Japanese Edition』の第4版を公開しました!

leanpub.com

今回は、読者の皆さんから頂いた指摘を反映しております。

ご指摘の連絡をしていただいた方々、本当にありがとうございました!

また、まとめ買いできるようにオプションを追加しました。社内勉強会のため社員数分だけ購入したいなどの際にご活用ください。

Leanpubページに移動したら、赤枠部分を「10冊セット」に変更することで、10冊分のまとめ買いが可能となります。また、最低販売価格も10%OFFの$135($13.5×10)となっております。

f:id:nihonbuson:20210803092252p:plain
まとめ買いの方法

書籍『テストコードの注入から始めるレガシーコードのリファクタリング』の公開

7月26日に書籍『テストコードの注入から始めるレガシーコードのリファクタリング』を公開しました!

nihonbuson.booth.pm

leanpub.com

Paypal(※PayPayではありません!)での支払いが可能な方は、価格が安いleanpubでの購入をオススメします。

レガシーコードのリファクタリングの書籍ではあまり記載がない「テストコードをとりあえず書く」という部分を中心に、実際のリファクタリング過程を言語化して書籍にしました。

この書籍の第1章の途中までは、上記のLeanpubページにサンプルとして無料ダウンロードできるようになっています。また、以下の記事にも掲載しております。購入判断の参考にしてみてください。

nihonbuson.hatenadiary.jp

また、第3章は今年のJaSST'21 Tokyoでの講演でも題材にしたものを、解説を増やして紹介しています。

www.jasst.jp

さらに第3章については、付録としてライブコーディングの動画も載せています。(これもJaSST'21 Tokyoの時よりもさらに詳しく説明しています)

謝辞

書籍公開に向けてはたくさんの人にご協力いただきました。

翻訳本の2冊については、原著者の協力はもちろんのこと、書籍内容について多くの人に見ていただきました。

また、『テストコードの注入から始めるレガシーコードのリファクタリング』については、TDDBCの皆さんに実際にリファクタリングの様子を見ていただき、さらなるアドバイスを頂きました。

本当にありがとうございました!

『A Practical Guide to Testing in DevOps』を翻訳して公開しました!

2017年8月に出版された『A Practical Guide to Testing in DevOps』を日本語に翻訳してLeanpubにて公開しました!

表紙はこんな感じ。*1

f:id:nihonbuson:20210802234628p:plain:w200

書籍紹介および購入はこちらから。

leanpub.com

現在は電子版のみ提供する形になっています。形式はpdfです。

本書籍について

出版ページにも書いている紹介文を引用して紹介します。

強力なコラボレーションと素早いデリバリー文化へ組織が移行するにつれて、テスターへの期待は変化します。

自動化されたビルドパイプラインおよびデプロイメントパイプラインがある環境でのテストはどのように見えるのでしょうか?

本番環境でテストできるようになると、リスクに対する欲求はどのように変化するのでしょうか?

テスターは組織全体で誰とつながる必要があり、どのように効果的に連携して高品質のソフトウェアをデリバリーできるのでしょうか?

この本は、DevOpsでのテストに携わるすべての人へ、方向性とアドバイスを示します。

私は以前に、『Agile Testing Condensed』を翻訳し、公開しました。

leanpub.com

Agile Testing Condensed』は主にシフトレフトのテスト*2について書いているのに対し、『A Practical Guide to Testing in DevOps』は主にシフトライトのテスト*3について書いています。

個人的な本書籍の見どころ

本番環境を用いたテストプラクティスの用語を解説している

例えば下記の用語などを、きちんと区別して説明しています。

  • A/B テスト
  • ベータテスト
  • カナリアリリース
  • ドックフーディング
  • ダークローンチ

事例がふんだんに書かれている

セクション5では、下記の会社の事例が紹介されています。

  • King社(ゲーム「Candy Crush Saga」を開発している会社)
  • Capital One 社
  • TheGuardian社
  • ニュージーランド銀行
  • Etsy社
  • Spotify
  • PagerDuty社

また、他にも様々な事例や発表を紹介しています。

グラフィカルなテスト戦略が紹介されている

セクション6では、著者が作成したグラフィカルなテスト戦略の図が紹介されています。

特にDevOpsのバグフィルターは非常に興味深く、共同翻訳者のMarkさんや、翻訳に協力していただいた山口さんもそれぞれブログ内で紹介しています。

f:id:nihonbuson:20210803000411p:plain:w200
DevOpsのバグフィルター

note.com

teyamagu.hatenablog.com

また、8月4日にはDevOpsのバグフィルターをトークテーマにしたイベントをMarkさんが開催しますので、ご都合の合う方はこちらへのご参加もどうぞ!

markin-quality.connpass.com

価格について

本書籍は価格を買い手が自由に決められます。

推奨価格は$14.99ですが、無料でも購入(ダウンロード)いただけます。

より多くの人に知ってもらいたいという原著者の考えを元に、このような設定をしています。

興味がある方はぜひご一読ください!(そして、お金を払っても良いよという方は、ご購入をよろしくお願いします)

謝辞

本書籍の日本語翻訳版を公開するにあたり、たくさんの方々にサポートいただきました。

特に、著者のKatrina Clokieはもちろんのこと、共同翻訳者のMarkさん、協力者として載せさせていただいた山口鉄平さんには非常に多くのサポートをいただきました。本当にありがとうございました!

そして本を手にとっていただいた皆さんも本当にありがとうございます!

Agile Testing Condensed』と同様に、本書籍に書いてあることが世の中に浸透していくことを願ってます。

*1:できるだけ表紙のイメージを崩さずにしつつも、日本語版であるであることが分かるようにしました

*2:開発プロセスの早い段階でテスト活動を行うこと

*3:開発プロセスの遅い段階でテスト活動を行うこと