スーパーで荷物をカゴ→カバンと移し替えるときはハノイの塔を思い出せ

スーパーで買い物をしたとき、店員さんがまずカゴに詰めてくれます。店員さんは気を遣って下に重いもの、上に軽いものというように積んでくれますが、カゴはFILO(先入れ後出し)なので、上から順にカバンに詰めると今度は下に軽いもの、上に重いものが来てしまいます。

これを解消するにはどうしたら良いのでしょうか？

A. 机も使ってハノイの塔の要領で入れる

上の図、見覚えがありませんか？そうです、ハノイの塔と酷似しています。ハノイの塔は棒が3本でしたので、カゴとカバンと机があれば完全にハノイの塔に落とし込めます。

まさかハノイの塔が日常生活で役に立つことがあるとは…

補足: 計算量について

ハノイの塔は荷物がN個あると 2^N - 1 回移動させなければいけないので、一見すると非常に面倒に思えます。が、別にハノイの塔そのものではないので、律儀に1つずつ移す必要はありません。たとえば上から3つまとめて移動すればその分早くなります。まとめて移動すればN=3、ほとんどの場合はN=2のハノイの塔になるはずです。

32文字以下かつアンダースコアを1つ以上含む文字列を正規表現で判定する方法

さて、タイトルにある通りです。「32文字以下かつアンダースコアを1つ以上含むか」を正規表現だけで判定してみましょう！

(もちろん str.length <= 32 && str.includes('_') で判定できるしそうすべきなので、この記事に実用性はありません)

解答:

さて早速解答です。こちらになります。

/^(?=.{0,31}_).{0,32}$/

ポイントは肯定先読み(lookahead)です。肯定先読みを使うことで、「直後に任意の文字が0個以上31個以下とアンダースコアが続く位置」を指定できます。あとはその位置から後ろが32文字以下であると確かめれば完璧です。

さらに: アンダースコアをちょうど1文字だけ含む場合

先程はアンダースコアが1つ以上という条件でしたが、今度はより難易度を上げてアンダースコアがちょうど1個だけのケースです。

/^(?=.{0,32}$)[^_]*_[^_]*$/

腹立つ絵文字みたいになりました。

今度はあらかじめ肯定先読みを使って「32文字以下である」と確定させています。その後ろの部分で _ が1つしかないかどうか調べています。

スナップショットテストの意義

スナップショットテストとは?

レンダリングした結果のDOM構造をテキストベースで書き出し、その結果が前回と変わっていないかをチェックするテストです。DOM構造が一切変化してないことを保証できます。

スナップショットテストの意義

A. コードを変更した時、DOMツリー(あるいは仮想DOMツリー)が変化してない = ユーザーから見たときに画面が崩れていないことを保証できるのが意義

DOMツリーもCSSも完全に同じであれば、ユーザーから見える画面は同じままのはずです。逆に、画面が変更になったのにスナップショットテストが落ちなかったら、コードがどこかで間違えていることがわかります(こっちが有難いことあまりないけど)

スナップショットテストは特に、単なるプレゼンテーショナルコンポーネントのテストとして有効です。ボタンなど動作が絡むコンポーネントがなければスナップショットテストだけ書けば十分なこともあります。

無限のQAリソースほし〜〜〜〜〜〜〜

無限のQAリソースで出来ること

無限のQAリソースと無限の時間さえあれば、こんなことができます！

• 躊躇なくライブラリをアップデートできる (なぜならQAリソースが無限だから)
• 抜本的なリファクタリングができる (なぜならQAリソースが(略))
• アーキテクチャを丸ごと書き換えられる (なぜならQA(略))
• リポジトリ丸ごと捨てて新しく書き直してもいい (なぜなら(ry
• テストを書かなくていい (ry

いかがでしたでしょうか?

現実はそう甘くはない

現実を見よう。QAリソースは有限だし、QAに無限の時間はかけられない。ちゃんとテストを書いて、QAコストを下げよう。

競プロとアプリ開発はテストの書き方が違う

tl; dr アプリ開発でコーナーケースを網羅する必要はない。 まず正常系を一通りテストするのが最重要。

競プロでは「関数がインプットに対して正しくアウトプットできているか?」に意識が向きがちだが、この意識はアプリ開発には向かないんじゃないか?というお話。

そもそも全ての関数をテストしなくていい

そもそも全部の関数をいちいちテストしなくていいんじゃないか。なぜなら 労力に対して見返りが少ないから。 もちろん、各関数にテストがあればそれに越したことはない。が、関数よりもっと上の層、つまり関数を使って作るアプリケーションをテストすれば十分なはず。そして、アプリのテストは一般的に「関数の入出力のテスト」とは見た目が少し異なる。

アプリの入力は「ユーザー操作」、出力は多種多様

アプリのテストにおいて、「ユーザーが行った操作」が入力、「それに対するアプリのアクション」が出力だ。そして、アプリの出力はかなり多種多様である。

ざっと例を挙げてみる。

• 画面を再描画する
• サーバー上のデータを変更する
• ページを移動する
• ダイアログを表示してユーザーにさらに入力を促す

もちろん、サーバーのデータ変更 や 画面の再描画 はさらに無数に分解できる。

出力が多様なので アプリのテスト方法は多岐にわたる。 関数のテストは入力に対して出力を確認すればいいが、アプリの場合は確認方法がそれぞれ異なる。「ページ遷移が発生するか?」「サーバーAPIを叩いたか?」「画面が期待通りに変わったか?」など、それぞれ書き方が違う。

そのため、アプリの正常系をテストするだけでもかなり大変である。エッジケースのテストを追加する余力はほとんどの場合ない。

まとめ: アプリのテストはまず正常系をしっかり確認しよう

これまで見てきたように、assert(solve(arg1, arg2, arg3) == expected) のような単純なテストをアプリ開発で書く機会は殆どない。コーナーケースへの意識は重要だが、コーナーケースを網羅することだけがアプリのテストでないのは確かだ。

まずは正常系のテストをちゃんと整備しよう。そして余力があればテストパターンを増やそう。ただし、たくさん増やしてもテストの成果は劇的には上がらないことに注意しよう。