  |
はてなキーワード: テストケースとは
GoMockってのはGo言語のライブラリで、依存するinterfaceをテスト用モックに置き換えてくれる。
それで、テスト中のモックの期待される振る舞い等を簡単に定義できるのだ。
期待される振る舞いってのは、モックのメソッド呼び出しやその引数とかだな。
期待される呼び出しが無かったり、引数が違ったりするとテストが失敗してくれる。
非同期処理のテストだとよく、wg.Done()をモックにさせたりする。
けれどそのうち辛くなってくる。
つまり、たくさんのinterfaceに依存するサービスオブジェクトのメソッドをテストしようとすると、たくさんのモックのたくさんのメソッド呼び出しの全部の期待される振る舞いを書かないといけない。
モックのメソッドの戻り値によってサービスオブジェクトのメソッド内の挙動が変わる。
すると連鎖的に、メソッド内で続いて呼ばれるモックに期待される挙動も、変わる。
依存interfaceが増えるとこの場合分けが指数関数的に増える。
当然だ。
Go言語にはテーブルドリブンテストっていう、テストケースは配列に簡単にまとめられると良い、という慣習・哲学がある。
しかし俺のサービスオブジェクトはテストケースが肥大化複雑化しすぎてしまったようだ。
モックの期待される挙動を細かくケースに分類して配列にするのは恐ろしく辛い作業だ。
やりたくない。
どうしてこうなったかは明らかだ。
モノシリックで巨大で複雑なものは凡人には扱えないからやめとけ、と偉い人は言う。
やったよ（見様見真似で）。
でもじつはここはまだ山麓だったのです。
分け入っても分け入っても青い山。
おれはどこに行けばいいのだ。
参考文献
https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
1. Markdown, Textileは知っていた。
2. 「何か新しいことを覚えようかなぁ」というコレクター魂のようなもので、reStructuredTextの手を付ける。
3. Sphinxなるものを知る。Pythonとから、Djangoとか、あの見慣れたチュートリアルを作るドキュメントツールがSphinx。
4. 面白いのだけど登場人物が多くて話が追えないなろう系のメモとして使ってみる。
6. LaTeX記法での数式表現、Matplotlibの機能に感動する。
8. 索引ページに気づく。
9. 日本語表示がイケてない。微分なら「は」の項目に、積分なら「さ」の項目に表示してほしいじゃん？「微」「積」の項目なんよ。。英語と同じように「頭の一文字」を取ったらそうなるよね。
10. 探してみたら、「Yogosyu」というプラグイン（※Sphinxでは拡張モジュール）があった。使ってみる。
11. 最新のSphinxに対応していない。ここからPythonのコード解析へと逸れる。
12. 取り敢えずエラーはでなくなったけど、元々索引ページとは関係ない機能だった。同一「用語集」での表示順が日本語に対応するだけ。
13. （しばらく放置）
14. 「単語の先頭に振り仮名を付け足せば、いい感じにソートしてくれる？」と気付く。
15. 表示の直前で「振り仮名」を取除くために、どこで表示しているか探す。
16. （紆余曲折）
18. ここで初めて「プラグイン形式にすれば良くね？」と気付く。
20. 出来上がって喜ぶ。
21. ここで初めて「これってクラスにしたら、全体の見通しが良くなったりする？」と気付く。
22.（この辺りで、unittestモジュールに手を付ける）
23. テストケースのお陰でリファクタリングが怖くない。喜ぶ。
24. setup.py, setup.cfgの書き方を学ぶ。
25. pypi公開を果たす。誰にも知られずひっそりと…
26. テストケースにjinja2を通した結果も加える。一人で成果に喜ぶ。
27. githubに手を付ける。学ぶ。基本的なことは覚える。
30. teratailに登録。コソコソ。「何がなんだか分からない」では質問しないし、そのうちどうにかなることが多い。先駆者に感謝。
32. coverageを知る。学ぶ。基本的なことは覚える。
33. circleciを知る。学ぶ。基本的なことは覚える。
34. カバレッジが90%を超えて喜ぶ。←今はこの辺。
※ボッチの日常
会食の例をまとめると、上記のようになるだろうか。
では、テストケースを考えてみよう。
問題になっているのは「対面でのマスクなし会話」。そして、飲食時にマスクを外して対面になるよう座るから、それをバカにでも分かってもらえるように「食事はひとりで」と説明しているにすぎない。
そんなことでこの冬を乗り切れるのか？
自分の仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分で作業に当たったりと色々なんだけど、
最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分の案件にアサインされた。
内容としてはとあるテーブルの特定カラムのバリデーション処理が漏れているから追加してもらって、なおかつユニットテストを修正する、というもの。まあ簡単な奴。
Issueを振ってからしばらくすると同僚エンジニアから質問が来た。
「ん？」と思った。いや別に特殊なことなんて何もないIssueだし似たようなテストケースもリポジトリ上に山程あるしどうにでもなるじゃんって。
まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合のテストケースを網羅してください」みたいな返信をした。
しばらくするとまた質問が来た。「△△の場合のテストケースの実装方法がわかりません。」
いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有のビジネスロジックのことを聞かれるならわかるけどこんなレベルの対応どの企業のどの案件で振られても同じことやるだけやん。
この質問してるのが未経験の入社1ヶ月目の新入社員なら自分は笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。
その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。
成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。
自分はITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラやインタプリタレベルの不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。
こんな公式ドキュメントとデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。
その人はとにかく「わかりません」が多い。
レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。
うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。
こっちもいろいろ対策を考えた。
Issue振るときはソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。
でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。
もはやその人に仕事を振るのは「この作業を担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。
最低でもあと1年くらいは人事はこの状況らしい。。。
こういう状況ってどう扱うのがいいんだろうなぁ。
とある日本の大企業に転職して３年経った。この３年、失望し続けることばかりでつらくなってきたので、ガス抜きにここに書こうと思う。
私は以前、とあるメガベンチャーに勤めていた。仕事はハードであったが、充実していた。結婚し子供が生まれ、育児しながら仕事をしていくのは少し難しかったため、業務時間が短く、保証も充実している日本的大企業に転職することにした。
大企業の仕事はお遊びだった。偉い人のお気持ちをまとめて、要件らしい何かを書き、それをベンダーに丸投げする。仕様書も、テストケースも、負荷試験も、自分たちでは何も理解していなかった。ベンダーからの成果物を、何も理解せず、検証もせずに受け入れていた。当然いくつかのプロジェクトは最後になって破綻し、すべての責任をベンダーに投げていた。
私は以前の会社で、すべてを実施していた。そのため、それらをそれなりにこなせる私は重宝された。私は入社して数ヶ月でプロジェクトリーダーになり、そのプロジェクトを成功させた。私が最初にいた企業では当たり前水準を満たさないようなものだったが、それでもこの企業では大きな成果だった。それ以降、数日おきに偉い人が自分の持っているプロジェクトについて意見を聞きに来るようになった。
私が彼らに話したのはシンプルな話だった。有名なマネジメントの本をよく読み、その知識を元にベンダーとよく話し、彼らの言葉をしっかりと理解し、無用な負荷を与えないように最も重要な課題にのみフォーカスできる環境を整える。本に書いてあることをちゃんと実践する。それだけだ。それだけのことが、驚くほど彼らには伝わらなかった。最初はプロジェクトの相談だけだったのが、計画書、仕様書、テストケース作成の仕事が回ってくるようになった。倍以上の年齢の人が仕事を渡してくるのだ。当時20代の私はうまく断ることができなかった。平日は深夜まで働き、休日も多くを仕事に費やして、なんとか回るような状態だった。
そして気がつけば、２つのプロジェクトのリーダーとなり、３つのプロジェクトのアドバイザーになっていた。だが当時20代の私は、肩書のない平社員のままだった。平社員の私が私よりも数段上の役職の人間に、彼らのプライドを最大限守りながら業務指示を出していた。
アドバイザーとしての仕事は、偉い人の非現実的な妄想を聞いて、それを現実的な着地点に収める計画書を作るといったものだ。偉い人は自分で依頼した仕事について、何も理解していない。そのため、ベンダーからの成果物も私が検品し、何も勉強していない足りない頭でも理解できるように解説して渡した。仕様書通りの成果物がベンダーから提供されたときも、偉い人間が癇癪を起こし、やり直しになることもあった。
この大企業は、若者たちの多くが優秀だった。みな学習意欲が旺盛で、プライベートでは様々なプログラミング言語やクラウドについて学習し、今の仕事に取り込むために知恵を振り絞っていた。若者達は多くを学んでいるため、上の人間の間違いによく気づき、それとなく指摘した。上の人間は知識では勝てないので、怒りの感情でそれに対処した。若者達は今の仕事で実績を作ったあと、AmazonやGoogleに転職していった。残されたのは、学習する習慣の無い、高学歴で、間違いを指摘するような精神性を持たない者達だけだった。
この企業は年功序列であり、優秀な人は見切りをつけて退職していく。そして、学習意欲のない、無能で、間違いを指摘しようとしない人間のみが残る。そして残った無能な人間が偉くなっていく。きっとこれを止める手立ては何もない。これが３年間の間に私が認識した、日本が誇るとある大企業の現状だ。
というか、
ＡＳＩＣやＬＳＩを作ったことある人なら、当たり前すぎることなんだけど、
語弊があるどころかニュアンスが逆なんだよね。
開発者にとって楽になるどころか難しい方向に行くんだよね。
「フロントエンドのみArm命令に置き換えた形」という文言は、
「中身は前のまんまw」「命令セット入れ替えただけなんすわw」「命令デコーダをarm化したSparc64です。」という意味ではなくむしろ逆で、マイクロアーキテクチャが共通になるように、DDRとHBMの差分を見えなくしたりレイテンシを調整したりetc...して、ほとんど全部Verilogを書き直したってことなんだよね。
で、なぜそこまでしてマイクロアーキテクチャを共通化するかっていうと
LSIチップの検証って組み合わせパターンが天文学的数字すぎて分岐網羅とか全然できないんだよね。
ソフトウェア的な分岐網羅に換算したら0.1%となんじゃないかな。
そこでマイクロアーキテクチャを共通化してると、過去チップのLSIテストケースを流用できるわけなんだな。
