00:03
はい、8月7日日曜日ですね。 遅刻は朝9時を回りました。
本日の時はちょっと曇りですね。まあ、雨降らなければいいなと思いますけど。
はい、おはようございます。ひめみのkeethことくわはらです。
では、本日も朝活を始めていきたいかなと思います。
本日はですね、タイトルある記事でですね、新しいビューポートの単位っていうのが導入されていたらしいですね。
僕、全然知らなかったんですけど、この記事見るまでは。
はい、っていうので、そこをざーっと見ていきたいと思います。
で、もう一個ですね、Adversarial Testingですね。
テストについてのちょっと短いエッセンス的な記事があったので、
その辺をばーっと読んでいこうかなと思っていきます。
はい、じゃあ行きましょう。
はい、だいちさんとプテルノドゾさんですね。
はい、ご参加いただきありがとうございます。日曜の朝9時という早い時間から。
皆さん勤勉ですね、本当に。はい、ありがとうございます。
じゃあ早速読んでいきたいと思います。
一つ目ですね、新しいビューポートの単位っていうところですね。
SVとLVとDVってやつですね。
はい、今回の執筆者の方がその密泳リンクスっていう会社かな?
なんですけど、密泳リンクスでは全社的に
インテルオップ2022の重要分野について調査をしていますと。
今回その中から新しいビューポートの単位について
紹介をしていきますよというところでした。
インテルオップ2022っていうのは僕全然よくわかってないんですけど、
ちょっとリンクが貼られてるので開いてみましょうか。
インテルオップ、Web Platform Test Dashboardって書いてあって、
インテルオップ2022のダッシュボード。
なんかスコアですね。
ブラウザーエンジンがどのように表現してるかっていうものの
スコアを出しているダッシュボードがあって、
その中にいろんな項目ごとにバーっと数値が取られてるんですね。
その中でビューポートの技術があったので、
そこについて研究していこうというところだそうです。
はい、行きましょう。
ビューポートってそもそも何とやるってことですけど、
釈迦に説法かもしれないですけど一応読んでいきます。
ビューポートっていうのはウェブページを表示するための領域の話ですね。
ブラウザーウィンドウからアドレスバーなどの
そのUIを除いた部分がビューポートっていうところになりますよってことでした。
ビューポートの単位っていうのは相対的な長さの単位で
ビューポートの長さに従って指定をしていくよってことです。
ブラウザーで表示したビューポートの長さが対象となるため、
アットページで宣言した印刷用のスタイルでは無効になりますよっていうことですね。
昔ながらはそういう名残でした。
はい。
なぜ新しいビューポートの単位が必要になったのかっていうところを
ちょっと研究していこうかと思います。
従来のビューポートの単位っていうのは
UIがスクロールによって拡大縮小するような機能を持つ前に作成されましたと。
苦闘点がないからちょっと日本語難しいですね。
ビューポートの単位はUIがスクロールによって拡大縮小するような機能を持つ前に作成されました。
そのため後発の動的にサイズが変わりUIに対応しておらず
画面をスクロールする前の初期表示に決定されたビューポートサイズを維持し続けますよと。
すると動的UIのサイズが変更されたときに
03:02
サイズの差分がビューポートに収まりきれずに
はみ出してしまうような現象が発生しますと。
例えばですね。
これ画像があるんですけど。
スマホであるウェブページをアクセスしたとしましょう。
そのときに初期レンダリングのときの
ビューポートですね。VHを使って表現していたとしましょう。
動的UIの縮小時と動的UIの拡大値があるんですけど
拡大値の縮小時では
拡大した分だけコンテンツが下にはみ出してしまうと。
例えば100VH出しているときに、初期に出していた100VHのサイズと
拡大したときのサイズっていうのはやっぱりもちろんズレがあるので
その分下にはみ出してしまうよというところでした。
これを解決するために作られたのが
新しいビューポートの単位になりますよというところです。
新しいビューポートの単位を使用すると
UIの拡大縮小に合わせたサイズ設定というのができるようになります。
例えば今さっきのやつだと100VHでやっていたデモですね。
なんですけど今回は100LVHかなっていうのを指定しています。
そうすると動的UIを拡大した分だけコンテンツが隠れてくれるみたいな
ようにちゃんと合わせてくれるようになるところですね。
これ結構多いし、実際見てもらう方もこれは分かりやすいと思います。
すみません、僕しか今見えてないんですけど。
というところですね。
従来のビューポートの単位ですね。
新しいビューポートの単位は従来のビューポートをベースに作られていますので
まずは従来のビューポートの単位については軽くおさらいしようかというところです。
従来のビューポートっていうのは大きく4つですね。
VWとVHとVmin、Vmaxってやつですね。
VWとVHは名前通りですね。
ビューポートの幅のパーセンテージ大ですね。
Hの方はビューポートの高さのパーセンテージ大ですね。
100で指定すると100%なので全画面のサイズになりますよということですね。
Vmin、Vmaxっていうのはビューポートの、例えばVminだと
VWとVHの小さい方のサイズですね。
VmaxはVWとVHの大きい方のサイズっていうのを自動的に指定するようになりますよということでした。
対応ブラウザって基本的には全部対応してますよというところですね。
これが従来のビューポートの単位になりますと。
新しいビューポートの単位ですね。
新しいビューポートの単位はW3Cにワーキングドラフトがあって
そこの中のCSSバリューズ&ユニッツモジュールレベル4ですね。
新しく追加になった単位というのが指定されているらしいですね。
もうすでにW3Cでちゃんと議論されて実装されたそうです。
その単位は以下になります。
それがVIとVBというものになるそうですね。
で、VIっていうのはルート要素ですね。
HTML要素のインライン軸。
横書きの場合は水平方向で縦書きの場合はもちろん垂直方向。
06:02
におけるビューポートのサイズのパーセンテージ単位というのがVIですね。
VBっていうのはルート要素、HTML要素のブロック軸ですね。
もちろん横書きは垂直か、縦書きが水平になります。
ブロック軸の場合とインライン軸の場合で横書きと縦書きの方向が変わりますよ、逆転しますよということですね。
それにおけるビューポートのサイズのパーセンテージ単位というのがVBだそうです。
それぞれのVI、VBに対しての単位がたくさん書かれていて、
あとSVW、SVH、SVI、SVB、SVmin、SVmaxみたいなやつですね。
これら全部小さいビューポートのパーセンテージ単位だそうです。
大きい方のやつはさっきのSがLになります。LVなんたらかんたらってやつですね。
が大きいビューポートのパーセンテージ単位で、
動的のビューポートのパーセンテージ単位というのがさっき出てきたDがついたやつですね。
DVW、DVH、ほげほげって感じのものですね。
各単位の頭文字、Sはもちろんsmall、Lがlarge、Dがダイナミックで動的というのを表しているというところですね。
今後はデフォルトでD使うんじゃないかなと思いますね。
これくらいのVW、VHだと結局動的にサイズを変更するようなサイズを作るときにはほぼ使わなくて、
全部みんなDを使うんじゃないかなと思ったりしています。
100のSVHとか指定しておくと小さい方のビューポートが指定されていて、
LVHを指定しておくと大きい方のビューポートになって、
DVHを指定しておけばサイズに合わせて勝手に変動してくれるというところですね。
最初からサイズが決まっているのであればSVHとかLVHを使うかもしれないですけど、
たぶん基本的にはDVHを使っておいて、ヨシナにやってっていうのがいいんじゃないかなと思ったりしていますね。
それぞれ小さい方のビューポータインと大きい方のビューポータインの若干の説明があります。
重複する気がするので、今回一番見たいのは動的ビューポートのパーセンテージタインと思いますので、
Sの方は割愛してDの方だけ見ていこうと思います。
動的なビューポートを設定することで、動的に拡大縮小するUIのサイズに合わせても
コンテンツがビューポートに収まるように自動で調整をされます。
使い方は基本的に従来のものとほぼ一緒ですね。
例えばVW、VHのDが付いたやつですね。
DVWとDVHはその動的なビューポートの幅とか高さに合わせてって感じです。
ブラウザウィンドウの幅から動的に拡大縮小するUIの拡大縮小を自動で判定して調整した幅とか高さを指定してくれるというところですね。
とりあえず困ったらそれをしておけば勝手にしてくれるのでいいんじゃないかというところですね。
DVIとDVBですね。
途中で出てきたインライン軸におけるビューポート幅のサイズと
09:02
ブロック軸における動的なビューポートの幅サイズを指定するものですね。
横書きの場合はDVW、縦書きの場合はDVHと同等のサイズになるというのがDVIのほうですね。
DVBのほうは横書きの場合はDVHで縦書きの場合はDVWというところで
先ほどのDVIとの逆転をしたという感じですね。
MIMMAXは文字通りDVWとDVHの大きいほうのサイズ。
MIMはその逆ですよというところですね。
基本的な使い方は従来のほうとほとんど一緒だという感じです。
対応ブラザーですね続いて。
対応ブラザーですけど、VIとVBは今のところサファリとファイアフォックスで
実はChromeが対応しないんですねまだ。
というか他のやつも全部のきなみファイアフォックスをサファリで実装はされてますけど
Chromeはまだっぽいですね。
この記事を書かれているのが先月の28日に書かれているので
まだちょっと対応されてない気がしますね。
サファリとファイアフォックスはそうです。
もしかしたら今見たら新しくなっているかもしれないですけどね。
一応書き方としてはですね。
従来の対応ブラザーの文の指定も入ってきたりするので
併用する書き方になる必要があるというふうに言ってますね。
対応ブラザー以外で使用する場合は従来のViewportの単位と併用する必要があります。
というところで例えばドットなんちゃらでクラスを指定しておいて
中身にハイトーのコロン100VHと
もう1個ハイトーコロン100DVHというふうに2つを書いていく
という必要があるんだろうなというところでした。
意外にもChromeはまだ対応しないんですね。
この辺はちょっとGoogleさんに早く対応してというのを待つしかないか
気はしますけどね。
一応今Can I Useをガーッと開いてみてますけど
Can I Useって単位まで見てくれるのかな。
出てきた。出ますね。さすが。
Can I Use見てますけどSafari、Firefoxの最新まで行けます。
Safari on iOSも行けますと。
Firefox for Androidも行けますと。
基本的には行けるという感じですね。
SafariとFirefoxは。
Opera、Edge、Chromeは全滅という感じで
まだまだ対応できないようというところでした。
もう多分じゃあもうちょっと先かな。
そして実践導入できるのも
Chrome対応してないとなかなか導入しづらいというのがあるので
難しいですけどね。
またiOSブラウザーにSafariは入ってくるし
日本人なんだかんだスマホ、まだiPhoneの方が確か過半数超えてたはずなので
iPhone、Safariを考えると
この辺のViewportの指定は書いておいた方がいいんじゃないかって気がしますね。
拡大縮小するのも結局スマホがほとんどメインだと思います。
PCでそんなに拡大縮小することはないと思うので
この辺ちょっと注目しておくべきかなとフロントエンジニアとしては思いました。
最後まとめですね。
新しいViewportの単位が加わったことで
動的用意の状態を合わせたViewportを基準として
12:00
意図通りのコンテンツを設計できるようになりました。
今回のIntelop 2022の取り組みに合わせて
新しいViewportの単位の調査を行いましたけれども
この単位に関してだけでも
問題提起から解決に向けての各ブラウザの動きが分かりました。
すべてのブラウザで同じ見た目や振る舞いになることが当然だし
そうなっていてほしいと思っていましたが
それが自分の想像していた以上に簡単なことではないということに
この取り組みを通して気づき
日頃各ブラウザが足並みを揃えて対応させてくれるに感謝したいと思いました。
すげぇ大人なことをおっしゃられている。
まあでもそうですよね。
基本的に足並みを揃えてくださっての評価はありがたいことではありますよね。
というところですね。
はい、以上でした。
これはかなりでもざっと読みましたけど
新しいそのViewportの単位
特にDVなんたらってやつですね。
かなりありがたいですね、ほんとに。
とりあえずこれ指定しておけば吉田にやってくれるっていうのはほんとに大きいと思うので
ここはぜひぜひ導入していきたいなと思いました。
はい、以上が新しいViewportの単位の記事でした。
ここに載っていたインテルアップ2022っていうダッシュボードのリンクもあるので
それも後ほどツイッターでツイートします、リンクを。
ざっと見てもらえればといただければと思いますね。
各ブラウザですね。
Chrome DevとEdge DevとFirefox Nightlyと
あとSafari Technology Previewってやつですね。
その辺の開発者ツール系の視点で見ている感じがしますけど
に対していろんな観点でそれぞれのブラウザの点数付けをしますね。
スコアリングをしてそれについての記事とかリンクが一個一個貼られているような感じですね。
はい、というところです。
ではもう一個の記事でいきましょう。
もう一個の記事はAdversarial Testingですね。
アンオーソドックスなテスティングフィロソフィーっていうところの記事があります。
はい、じゃあこれを次は読んでいこうと思います。
次の記事こちらは英語なのでちょっと翻訳しますね。
はい、ではいきましょう。
テストの話はこの業界、特にソフトウェアエンジニアは永遠に付き合っていく話だと思いますので
しっかりテストを書いていくことは本当に大事なことでありますけど
メリットもかなり大きいので
メリットインパクトのことを考えても別に書いたほうが僕はいいと思ってますけど
その辺の話は別でもいろんなところでやられているので今日は加算します。
ではいきましょう。本文ですね。
ソフトウェア開発者としてのキャリアのかなり初期に
私はユニットテストに対する従来のアプローチが自分にとってうまくいかないよということに気づきました。
失敗したら修正しまた失敗したら修正するというように
言ったり来たりするのは私の脳にとってあまりにも不愉快なことでした。
まあそれはみんな思っていることだと思います。
いくらやってもこのように極端にタスクを抑え
タスクを細分化するとイライラしたりやる気がなくなったり
全体的に悲しくなってしまうので私には無理だったかなと。
なるほどこの人はそういうタイプの人なんですね。
小さくしすぎるとその分テッドとか使う範囲とか
管理するものも増えたりするのでそれはイライラするかもしれないですね。
幸いなことに私は非常に頑固な人間なので幸いなのかな。
でも辞めるつもりはありませんでした。
15:01
テストを諦める代わりにユニットテストを書くことが
あまりに好きになれるものを見つけるまではそのアプローチを実験しました。
とにかく見つけるというアプローチを辞めるつもりなく
ずっとやり続けたということですね。
あまりに好きなので実際に既存のテストスウィートを
リファクタリングしてテストのギャップを埋めるチャンスに
飛びつきました。
今ではテストに腹を立てることなくお愛顧です。
ここに素晴らしいギターリフを挿入してください。
うまくいったよというところを表したい画像が今載っています。
ギター弾いている画像が載っています。
海外の人はこの辺のウィット効いた感じを
載せてくるのが面白いですね。
日本のいろんな技術記事やブログを読んでいて
こういうことが出ることってほとんどないので
なかなか新鮮ですね。
海外記事を読むという面白いアレがあるので
おすすめです。
とりあえずこの人は好きになるものを見つけたというよりも
自分でリファクタリングしてギャップを埋めるという
アプローチに至ったそうですね。
それがいろいろステップごとに分かれているそうですけど
ステップは大きく2つしかないですね。
1つ目いきましょう。
ステップ1ですけど、よしまずはハッピーテストを書いてみるか
というところですね。
まずは単語を受け取って文字数を返す関数
怠け者なJavaScriptで書きますよと言いますね。
簡単な例とそれに対するジェストを使った
ちょっとしたハッピーテストをしてみましょうと。
今ソースコードをざっと抜いているんですけど
本当に文字列を見てそれがOKかどうかみたいなところを見ていますね。
ジェストの一般的なテストの書き方ですね。
メソッドの中でそのテストのケースが書いてあって
アロー関数でその中身を実行します。
エクスペクトで特定のそのメソッドですね。
あってそのメソッドの中で処理したものが
最後.2bでホギホギみたいなテストをしていますと。
これが通るかどうかみたいなのが書いています。
もちろんこれが通れば
オーサム100%テストカバレッジライトって書いてますね。
テストカバレッジ100%でOK。
出荷する準備できたなみたいなところが書いてますけど
これでテスト書いたらこういう感じになります。
続いてステップ2ですね。
ステップ2ですけども
ステップ2はBlow it upなので
膨らませましょうみたいに置いてますね。
1つ1個できたのでそれをどんどん膨らませていこうということですね。
正直なところだとこれだけ簡単だと
多くの人がここでやめてしまうんじゃないかみたいなところがありますけど
私は違いますよと。
私は自分のコードも他の人のコードも信用しないので
攻撃な顔してツッコミを始めました。
本当に表現が面白いな。
なるほど。
自分のコードもちゃんと疑うっていうのがすごくいい話ですね。
昨日の夜書いたコードが
今日自分が見てみると
いやこれバグってんじゃんみたいなのが全然よくある話ですし
3日前のコードなんて絶対他人ですからね本当に。
3日前の自分は他人です。
みたいなことがあるので
しっかりそこに対して疑いの目を見せるのはいいけど
攻撃的な顔をしてツッコムっていう表現がなかなか面白かったですね。
さっき見てたテストっていうのは
基本的な単なる文字列を見て
そこに対して
例えばundefinedを入れてみるとか
その文字列を対列の文字列ですね
18:00
を入れてみるとか
あと違う文字列を入れてみて
通りますかみたいな
いろんなパターンについて
テストを膨らませていっているということですね。
なのでアプローチとしては
基本的にまずベースとなる一つを作って
そこからどんどん膨らま、拡大していくっていうところに
この人のアプローチは移ったそうですね。
なのでテストツールとかをリファクタリングとかしたんじゃなくて
このテストそのものに対してガッと
リファクタリングをしたっていう感じだと思います。
一応この例っていうのは非常に単純化されすぎていますけど
目標を示すものであることを願っていますと。
そういうアプローチをしたというところですね。
私のアプローチは
関数が動作するかどうかをテストするのではなく
それがうまくいかない可能性のある
全ての方法をテストすることです。
エラーパターンを全部テストするという感じですね。
正常形じゃなくて異常形を
ひたすら洗い出すっていうようなアプローチ
多くの方はしているそうです。
関数が大きく複雑になればなるほど
何か奇妙なことが起こる可能性はもちろん高くなります。
そしてその奇妙なことが何であるかを知り
コードを実運用に移すずっと前に
それを先に説明してしまいたいのですと言っています。
テストコードがドキュメントであるみたいな
使用書であるみたいなことの裏付けの動きをしています。
先ほど誰のコードも信用しないって言ったのも重要なことですと。
私は何かおかしなことが起こるように
ユニットテストにテストダブルを多少対応することにしていますと。
これは結構いい話ですね。
テストダブルをどんどん使っていくことはいいと思います。
もちろん用法要領はあるんですけど
導入しておかしなことを意図的に起こすようにする
っていうのは素晴らしい話だと思いますね。
私が呼び出している他の関数が失敗する可能性が
本当に低いとしても私のコードが
それをどのように処理するかを確認するために
ダブルを使って何か奇妙なものを投げてみましょうと。
役に立たない例外が投げられるかとか
何がどこで失敗したかを見ることが
しっかりできますかとか
何が悪かったのがちゃんとログに残りますか
みたいな観点で見ているよってことですね。
通常私が既存のテスト、スイートで目にするものは
ロジックを実装し全ての可能なハッピーパスが
カバーされていることを確認することを
重点に置いていることでありますと。
私は90%のカバレッジのコードベースを見てきましたが
このために何か問題が発生したときに
デバッグ性能がひどく苦痛でしたと。
90%を通ってしまっているからこそ
逆に苦痛かもしれないですね。
それを1個直すと
他のところがどんどん我解していって
一気にカバレッジがガンと下がる可能性も
大いにありそうだなと。
カバレッジは何が足りないかを示す
良い指標にはなりますけど
遅刻しそうな子供に服を着せるような
コードと向き合っていないと
何かを見逃してしまうことになるのです。
遅刻しそうな子供に服を着せるように
コードと向き合っていないと。
要は後から来る何か変更だったり
そういうイレギュラーなことを
ちゃんと考えているようなコードを
書いておかないといけないということかなと
多分思います。
他の人生の道筋に関わる日々ですね。
クーラーに肉が入っていないことに気づいた熊とか
延長戦であと1タッチダウンで勝利する
クォーターバッグのようなものですと。
なるほどね。
21:01
本当に例えの表現は面白いな。
ちょっと分かりづらい表現もありますけど。
でもこのテストの手法は私にとって
もし何たらだったらどうなるかという
痒いところに手が届くようなものなので
ユニットテスト面白い方法で
ワイルドに行うこともできます。
またこのアプローチではそうではなければ
ユーザーが偶然発見するまで
見逃していたような驚くべきバグを
数多く発見し解決してきましたと。
今までそうですね。
ではそこからさらにレベルを上げていきましょう。
ステップ3ですね。
ステップ3があったそうです。
ステップ3ですけども
About Zoes Integration Testですね。
ここからはユニットテストを超えて
統合テスト、インテグレーションテストに
いきましょう。
他の全ての関数とかルートを呼び出す関数や
ルートを持ってパーティーをするときは
きましたと。
統合テストに関する私の一般的なルール
というのは最も重要なパスに焦点はあって
失敗の処理に専念することですと。
結局のところユニットテストは奇妙な
内部ロジックを全てカバーする必要は
ありますけどねって話してます。
結局のところはそうですけどね。
特にREST APIっていうのは
外部ユーザーに見られる可能性が高いので
これは非常に重要だと思います。
私は通常
私のメンターの一人が
5時の金曜日ルールに従うようにしています。
何がうまくいかなくても
毎週金曜日の午後5時に
家に帰れるくらい素早く修正できるような
十分な情報が欲しいんですよと言っています。
このことを念頭に置きながら
私は常に物事がうまくいく方法よりも
物事がうまくいかない方法
の方を重視していますと。
私は残業は嫌いですと。
情熱を持って
仕事を終わらせますと。
残業することは最悪ですと。
要はマンパワーになるということが
本当に嫌いだそうですね。
私のテストは戦略全体
私のテスト戦略全体
というのは残業を避けることじゃないと。
本当に面白いわ。
割り切ってるというか
ここまで潔く書き切っちゃうというところが
本当に僕は結構好きです。
こういう人は。
インテグレーションテストの話でした。
結局ユニットテストで
奇妙な内部ロジックを
カバーするというところが重要で
そこからさらにいろんなものを組み合わせていく
組み合わせていくんですけど
なるべく解決できるように
情報が早く欲しいと。
情報を明確にするということは結局
一個一個の関数だったりロジックを
明確にしなきゃいけない気はしますけど。
するとさっき言ったステップ2の
ロジックですね。
ユニットテストのところをしっかり詳細に書く
というのは結構大事なことかもしれないですね。
はい。
結局統合というのは
それぞれの問題自体をユニットテストのほうで
カバーできるというのが理想な気はしますけどね。
僕としては。
極ライトは
ユニットテストを全部通れば
本来アプリケーションというのは
動いていくというのがかなり理想だし
そういうアプローチをしている会社さんも
確かいたはずですね。
我々はE2Eと
インテグレーションテストを書かないみたいな会社さんがある
という話をどこかで聞いたことがあって
24:01
全部ユニットテストに全振りして
その代わりそこのカバレッジと
そのクオリティですね。
テストのクオリティに対して本気で取り組んだ
みたいな話を聞いて
すげえなと思いました。
ちょっと余談ですけど。
最後ですね。
ナイストライエビルコードですね。
ジャークなコードに挑戦しましょう。
実はこれがこの哲学の確信だと思います。
コードは私を嫌っていて
私に残業させたがっている。
コードはコードでしかないけど
なるほど。
コードが私を嫌って
の人とられてるんですね。
だから私はコードが私を待ち伏せする方法を
すべて見つけ出してそれを阻止しましょうと
考えています。
テストに敵対的なアプローチを取ることで
私は一般的に反復作業は嫌いなんですけど
それを克服することができました。
ゲームの対戦相手のようにコードにアプローチすることで
どのような方法で
ひどく失敗する可能性があるかというのはわかります。
それに物事を壊すのは楽しいことです。
あの用事に聞いてみてください。
物事を壊すのは楽しい
というのはちょっと危険な表現
というか
今回のグローブを読んでいてだいたいわかってきましたけど
面白いな
というところです。
この人の話、仕事してみたくなってきた。
というので
一応この記事は終わりました。
一応ステップを大きく3つに分けて
テストについての
フィロソフィーですね。
タイトルは副題にもありますけど
アサイトリーアンオーソドックステスティングフィロソフィー
に関するお話でした。
ほんとはノウハウとか
チップスみたいなところはしっかり加えつつ
テストどうなんだみたいな書き方の
記事も読みたいんですけど
だいたいそういう記事って
ソースコードだらけになってしまうので
多分音読しても僕しか理解しないみたいな話になっちゃうので
それはちょっと申し訳ないなというので
今回はフィロソフィー的な話に移りましたけど
何か参考になれば幸いです。
個人的にはただ単に面白かったという感じです。
あと考え方としては
割とでも近いというか
ステップ的にも同じだと思いますね。
まずベースのあるものを書いておいて
そこから発展させるというのはよくある話です。
そこから
僕もその
似たようなフローを取るんですけど
異常系ですね。
テストってひたすら異常系をどんどんやっていくという感じです。
正常系と異常系を比較すると
僕の経験値だと2対8か1対9ぐらいで
基本的には正常系少ないんですよ。
だいたい異常系のオンパレードなんですよ。
なので異常系をテストしていくのが
すごく大事なので
そこのどうやったら壊れますかというか
どんな結果にならないですかというのの
アプローチをだーっと洗い出すのが
僕も確かにテストだなと。
特にユニットテストだなと思ったりしてます。
なのでその観点に対して
どんどんまず正常系書いて
そこから異常系をどんどん
拡大させていくのがいい話だと思いますね。
その上で一個だけ
参考というか
僕が
考えているというか
参考にしている考え方というのは
テストに対しての
書籍があるんですけど
ソフトウェアテストの教科書という書籍があります。
有名な書籍なんですけど
この書籍の観点に従って
27:01
僕は結構テストを書くことが多いですね。
だいぶ古い書籍ですし
観点としても古いかもしれないです。
でも今は全然使えるし
バリバリ素晴らしい技術ばっかりで
テストの考え方や
フィルソフィーって実はそんな変わらなくて
使うツールとか
フレームワークとかライブラリーは結構進化したり
いろんなことができるようになったんですけど
テストするものとか観点って
実はこの何十年人類変わってないんじゃないかと
僕思っているんですよ。
その上でソフトウェアテストの教科書という書籍は
僕かなり良かったので
割とお勧めしています。
もしテスト今後からやるとか
ちゃんとテストについて勉強してみたいなって方は
もちろんツールから入って
こうやってテストを書くとか
エリントテストってこういうことをするんだっていうのを
知るのはすごく大事ですし
知ってから他の書籍を読むほうが
理解が早いのでそれはいいと思うんですけど
ちゃんとそういう読み物系の
テストの書籍を読むっていうのも
すごく重要だと僕は思ったりしています。
はい。ちょっと最後余談を投げましたけど
こんなところですかね。
じゃあ一旦30分過ぎましたので
今日の朝はこちらで以上にしたいかなと思います。
はい。今日もですね
朝9時から始めたのに
日曜日なんですけどこんなに多くの方に
いらっしゃって本当にありがとうございます。
はい。じゃあ日曜日ですねまた
もしかしたら来週一杯は
もう夏休み週間に入るみたいな
企業さんもあるかもしれないですけど
はい。皆さんいろんなことがあると思いますので
しっかり今日でまた
影響を養っていただいてまた明日から
月曜日ですね
動けるようにしていただければなと思います。
では朝からこちらで以上にしたいと思います。
お疲れ様でした。
