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

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

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

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

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

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

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

ざっと例を挙げてみる。

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

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

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

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

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

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

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

Prettier は結局何をやっているのか?コードの動作は変わってしまわないのか?

結論: AST を作って、それを元にコードをフォーマットしているから、プログラムの動作は一切変わらない

結論をもう書いたので、意味が分かった人はここより下は不要。ちょっとだけ用語とかの解説をする。

そもそも AST とは?

AST とは Abstract Syntax Tree のこと。超簡単にいえばインデントなどを消して、動作に関係する箇所だけを抜き出した構文木のこと。

たとえば以下の3つはいずれも同じ AST になる。

(1 + 2) * 3

(1+2)*
3

(((1+2))*3)

上の図はJAVASCRIPT AST VISUALIZER で生成した AST。3つとも同じ AST が生成される。このように、AST にはインデントや余分なカッコなどの余計な情報が一切含まれていない。

AST が同じなので、Prettier にかけてみると同じコードが出力される。Prettier にかけた結果がこちら

つまり Prettier は一旦正規化してからコードを生成している

AST について分かってしまえば Prettier が何をやっているかはすぐ理解できる。元のコードから AST を生成して(=正規化)、それをもとに整形コードを組み立てているのだ。一旦 AST の状態にすることでインデントなど整形に関する情報をそぎ落とし、そこから組み立てることで一貫性のある整形済みコードが生まれる。

以上の説明から分かる通り、Prettier はプログラムの動作に関係ない部分だけ変更している。 AST に変換するときもそうだし、AST からコードを生成するところもそうだ。コードのフォーマットに関する箇所しか変更していない。

ちなみに: Prettier は純粋な AST を組み立ててる訳ではない

Prettier はあくまで AST が変わらないように変換するだけで、内部では空白情報を持った AST を使っているそうです。

Prettier が使う AST には改行などの情報が残っていて、一部のケース(機械的にいい感じの改行を推測するのが難しいケース)においてはもとのコードの改行を尊重してフォーマットをしますhttps://t.co/gROnOyIcTM

— sosuke (@__sosukesuzuki) 2022年4月8日

参考資料

Prettier のしくみ - Speaker Deck

↑ Prettier の内部動作については、Prettier コントリビュータの方のこの資料が分かりやすい。

npm run で (Use `node --trace-warnings ...` to show where the warning was created) って出たら NODE_OPTIONS を使え

NODE_OPTIONS="--trace-warnings" をつけて run すれば OK

$ NODE_OPTIONS="--trace-warnings" npm run lint

以上。

スマートホームをスマホから操作した〜〜〜い！！

いちいち「Alexa、リビングの電気をつけて」みたいに言うの、かったるくないですか?僕は仕事で使ってるMacの充電器をスマートプラグで管理してるので、いちいち「Alexa、充電つけて」と言わないと充電ができません。これが地味に面倒だったので、スマホのホーム画面から家電のオンオフを操作できるようにしました。

方法: Google アシスタントで家電の操作ルーチンを作成する

大雑把な方針は、まずルーチンを作成して、そのショートカットをホーム画面に追加する。これで、ホーム画面から1タップで家電を操作できる。

まずルーチンの作成について。

↑Google home を起動するとこういう画面のはず。ルーチンを選択する。

ルーチン一覧の下に追加ボタンがあるのでタップする。

開始条件は「音声コマンド」を選択して任意のフレーズを入れる。あとはアクションを設定して保存する。

ホーム画面にアイコンを追加する

AOS であればルーチンのショートカットをホーム画面に追加できる。

iOS はもう一工夫いるので、iOSについてのみ解説する。

ショートカットを使ってホーム画面にアイコンを追加する(iOSのみ)

まず「ショートカットアプリ」をインストールして起動する。そしてショートカット追加ボタンをタップする。

↑するとこのような画面になる。この画面でまず「アクションを追加」をタップして「Googleで調べる」コマンドを追加する。question のところにルーチン作成時に設定したフレーズを入れる。

これで準備完了なので、あとはホーム画面に追加すればOK。

↑共有メニューにホーム画面に追加という項目がある。

ちなみに、ショートカットのウィジェットからも操作可能。僕はこっちを使ってる。

touchcancel イベントをハンドリングしないと iPad で大変なことになるぞ

結論: iPad は4本指で上にスワイプするとホーム画面に戻る便利機能があります。これをブラウザで行うと touchstart → touchmove → touchcancel の順で発火します。 touchend が永遠に発火しません。

結論で言いたいことは完結してるので、以下はその補足説明です。

iPad の4本指ジェスチャーについて

iPad で4本指まとめて上へスワイプすると、ホームへ戻るかマルチタスク画面を開けます。これがすごく便利で毎日100回くらいやってます。マジです。

4本指以外にも3本指のジェスチャもたくさんあります。さて、もうお分かりかと思いますが、iPad に対応するにはマルチタップ前提でアプリを作る必要があります。

4本指で上ヘスワイプしたときの挙動

4本指でスワイプしようとすると、touchstartがまず発火します。次にtouchmoveが発火します。最後にtouchcancelが発火して終了です。 touchendは呼ばれません。

touchstart イベントは3本分がまとめて1回で発火したりします。touchcancel は1回で4本分すべてキャンセルされます。何度か試してみましたがいずれも touchcancel は1回だけでした。

というわけで、touchcancel イベントは iPad に対応する場合は必ず設定しましょう、という話でした。

検証用ページ

今回、これを検証するにあたって touch event をログ表示する簡易ページを作りました。実際に試してみてください。

condescending-browser-ykh54i - CodeSandbox