たにしきんぐダム

プログラミングやったりゲームしてます

午前研究して午後仕事しようと思ったけど全然うまくいってない

東工大大岡山キャンパスの枯れ木と曇り空

2022年10月から大学院に復学して、大学院生活とヨーロッパの会社にリモートで働く二足のわらじをやっている。

日本と本社との時差は8時間(サマータイム中は7時間)なので、基本的にチームメンバーが仕事始めるのは日本時間の夕方以降。昼過ぎや昼前からぼちぼち仕事はじめて夜10過ぎくらいまで仕事をする生活をしている。

そんな感じなので午前中は大学のことやって、仕事は午後やるようにすれば完璧では???と思って大学院に復学してみたのだけれど...全然うまく行ってない。

そもそも今の仕事も研究もあまりスキマ時間でできるような感じになっておらず、午前中に研究っぽいことと行ってもちょろっと論文読んで研究した気分になってるだけ。あとは土日のどちらかにちょろっとすすめるくらいで全然進捗は出ていなくて、結局仕事ばっかりしてしまっている。(あと復学決めた直後に会社で締め切り厳し目なプロジェクトを任されてしまったのも問題かもしれない)。

自分はコンテキストスイッチそんな得意じゃない(得意な人間がいるのか???)し、仕事+研究で週7日10時間労働できる鉄人でもないので、やっぱりこの日は研究デーみたいなの作ってあげないとだめな気がしてきた。

稼働週4にして月か金は研究デー+土日のどちらかも研究デーってことにしようかなぁ...

仕事も大学も楽しくはあるので贅沢な悩みである。

コロナ禍2022年9月海外渡航メモ

カタール空港の熊

2022年9月14日-2022年9月25日にかけてポーランドの本社に出社するために海外渡航していた。

以前は日本に帰国するためには72時間以内に陰性証明書の提示をしないと日本に入国できなく(なので陽性になった場合はそのまま渡航先で陰性になるのを待つことになる)、海外渡航中にコロナ陽性になってしまった人のブログを見てひえ〜ってなっていたり、ポーランド国内でPCR検査を受けないといけないの面倒で不安になっていた

tomoima525.hatenablog.com

しかし渡航直前の8月末の発表で、9月7日からPCR検査は不要になった。ラッキ〜

水際対策の緩和では、9月7日から、ワクチン3回目の接種証明があれば、入国・帰国者全員に義務づけてきた出国前72時間以内の陰性証明書の提示を不要とする。

www.yomiuri.co.jp

9月7日以降の海外渡航の様子をメモしておく。ポーランド含む多くの国は僕のケースと同じだと思うけど、国によって対応は異なるので外務省のホームページをチェックしてね

外務省 海外安全ホームページ|新型コロナウイルスに係る日本からの渡航者・日本人に対する各国・地域の入国制限措置及び入国に際しての条件・行動制限措置

まとめ

  • (必須)ワクチン接種証明書を用意しておく
  • (optional?)日本に帰国する際にMySOSアプリを入れる
    • あらかじめセットアップしておくとスムーズ
    • 別にMySOS入れてなくても大丈夫そうだった

行きも帰りもカタール航空を利用していて NRT(成田)-DOH(カタール・ドーハ空港)-WAW(ワルシャワショパン空港)

  • 日本からポーランド
    • 本当に何もなかった、飛行機の中ではマスクしてくださいって言われたくらい
    • ワクチン接種証明書の提示も求められなかったんだけどいいのか?
  • ポーランドから日本
    • ポーランドで荷物を預ける際にパスポートと一緒にワクチン接種証明書の提示を求められた
      • ワクチン接種証明書アプリから英語のやつを表示して見せるだけでOK
      • フェイスマスクないと飛行機乗れないよってここで言ってくれた、親切
    • 飛行機のボーディングのときにマスクをつけておかないと通してくれない
      • 何人かマスク持ってなかったようだけど空港会社が配布していたような気がする
    • MySOSアプリを入れる
      • 入国審査の前のところでMySOSアプリのQRコード(?)をチェックする人がいた。このQRコードが後で必要らしい。
        • 多分VPNつないでたからかうまくアプリが動かなかった
      • MySOS動かなったけど、なんかアンケート(日本国内での滞在場所など)フォームが用意されていて、それに答えたらMySOSアプリの代わりにQRコードをゲットできた
    • 入国審査前に先程ゲットしたQRコードを提示するコーナーがある。ここでさっき手に入れたQRコードを見せると謎の青い紙をもらえる
    • 入国審査でさっきもらった青い紙とパスポートとかを見せて通過
    • これにて入国完了です。おつかれさまでした。なんかMySOSから健康状況を答えてくださいの通知がたまにくるので答えてるけど、必須なのかよくわからない。

全体的に成田の職員が日本語でばかりアナウンスをしていたので海外から渡航してきた人が困惑している様子だった、かわいそう(英語通じる人もいたのでなんとかなっていたが)。日本への入国もだいぶ楽になったけど外国人観光客の日本渡航はまだツアー限定だったりするので、まだ是非日本に来てくれよなとは言えない感じがする。

日本人が日本に帰国するのはかなり楽になったので、これで心置きなく海外カンファレンスとかにも行けるなぁと思った。

異文化理解力 ("The Culture Map" by Erin Meyer) を読んだ

最近いくつかの国の人々と仕事をすることが多かったり(ポーランド・ドイツを中心に周辺ヨーロッパ諸国)、大学院の研究関連で異なる文化圏の人々と話すことが多い。

今の所文化の違いによるミスコミュニケーションに大きな問題を感じていない(と思い込んでいる)が(実際はひとつ大きな失敗をしたことがあるのだが後に書くことにする)、異なる文化の人々とコミュニケーションをするに当たりなんらかの心構えを持っておくと良いだろうと思い、読んでみることにした。

内容には満足していて、異文化出身の人とコミュニケーションする機会があるならおすすめできる本だった。

(ちなみにこの本を知ったのは、以前大学院で受講した 2021年度 | 異文化協働とリーダーシップ - TOKYO TECH OCW という講義の参考書として紹介されていたからであった。東工大の学生の方がいたら是非受講をおすすめしたい。)


この本は各国の文化の8つの指標でプロッティングし、各指標についてケーススタディを交えつつ紹介していくという構成になっている。

各国の比較はこちらのページから見れる(有料)

erinmeyer.com

(これらの指標がどういうデータをもとに作られているのか見つけられなかった、知ってる人いたら教えて下さい)

  • Communicating: explicit vs. implicit
  • Evaluating: direct negative feedback vs. indirect negative feedback
  • Persuading: deductive vs. inductive
  • Leading: egalitarian vs. hierarchical
  • Deciding: consensual vs. top down
  • Trusting: task vs. relationship
  • Disagreeing: confrontational vs. avoid confrontation
  • Scheduling: structured vs. flexible

www.businessinsider.com

この本で紹介されている指標ではないが、以下のサイトでの文化の比較も興味深かった(こっちは無料)

www.hofstede-insights.com

以下は各項に関するメモ

introduction

  • 文化について語るときによく言われる反論に、人によって性格は違うのだからその人の属する文化圏ではなく、その人個人の性格を見るべきだという主張がある。この意見はもっともだし、もちろん個人によって各指標がどちらに傾いているかは異なる。
    • あくまで各国が各指標においてどこに位置するかは統計的なものであって、その文化圏における外れ値的な人はもちろんいる。
    • 各文化には幅があり、各個人はその幅のなかで選択を行う。文化か個人の性格かではなく、文化と個人の性格が問題。8つの指標を知ることは、文化的コンテキストの中で各個人の選択や性質を見極める手助けとなる。

  • 各文化の指標を読み解く際にもうひとつ大切なのが、指標の絶対値を見るのではなく、ある文化と比べてある文化がどこに属しているかという相対的な値に注目するべき
  • あなたがある文化の中にいるとき、その文化を見ることはしばしば難しく、不可能なときすらある。一つの文化でしか過ごしてない人は、地域差や個人差にしか目が行かないことが多く、そのため「この国の文化ははっきりとした特徴を持っていない」と結論づけてしまう。 (P42)

Communicating: explicit vs. implicit

  • 自分よりハイコンテキスト(implicit communication)な文化出身の人々と働く際の戦略
    • 何を行っているかではなく、何を意味しているかを聞くように心がける、相手の発言を吟味して、明確になるような質問をする
    • もし聞いたことに100%の確信が持てなかったとき、肩をすくめてメッセージをうやむやなままにしておくのは良い戦略じゃない。確信が持てなかったときは明確にするために責任をもって質問する。三度か四度聞かなきゃならないときもあって、自分も相手も少し気まずくなったりもするが...

    • 最大の過ちの一つは、相手が情報を意図的に省略しているとか、明快なコミュニケーションができないと受け取ってしまうこと。
  • 自分よりローコンテキストな文化出身の人々と働く際の戦略
    • できる限り透明で、明確で、具体的でいてください。電話した理由をきちんと説明してください。意見は透明性を保って主張してください。思っていることは全部表に出してください。電話の終わりにはキーポイントをもう一度繰り返すか、後でポイントを簡潔にまとめたメールを送ってください。言われたことが100$理解できなかったときは意味を汲み取ろうとするのではなく、理解できなかったとはっき伝えてください。

  • ハイコンテキストな文化を持つ人同士がコミュニケーションする場合が一番やっかい
    • お互いに多くを語らず、お互いが勝手に言外の(誤った)意味を汲み取り、ひどいミスコミュニケーションが起きてしまう。
    • なので、多文化のチームではローコンテキストなやり取りを心がけよう。

Evaluating: direct negative feedback vs. indirect negative feedback

  • 一般的にはハイコンテキストなコミュニケーションを行う文化では、ネガティブ・フィードバックも間接的な傾向にある。
  • しかし、ローコンテキストなコミュニケーションを行う文化であっても、ネガティブな批判は遠回しに行う文化(アメリカなど)やその反対の文化もある
  • ネガティブ・フィードバックを行うかを測定する指標の一つに、ネガティブな言葉の前に、(言語学で言う)"アップグレードする"言葉を前や後につけて発言するか、ダウングレードするか
    • アップグレード: absolutely, totally, strongly
    • ダウングレード: kind of, sort of, a little, a bit, maybe, slightly

Persuading: deductive vs. inductive

  • deductive
    • 結論や事実を一般的原理や概念から導き出す思考法
    • データや原理原則が有効な説得材料
  • inductive
    • 現実世界の個別の事実を積み重ねることで普遍的な結論へと至る
    • ケーススタディが有効な説得材料となる
  • 文化をまたいで説得を行う場合はデータとケーススタディをいったり来たりする方法
  • 一方、日本韓国中国などのアジア人は背景などの描写に敏感で、包括的な思考パターンを持つ
    • 特定の事例について話す場合も全体像を説明する時間をとり、互いがいかに影響しているかを説明するべき (この部分は自分にとって当たり前過ぎてピンと来なかった)
  • 多文化チームを効率的に率いるには?
    • 多文化チームにおいては文化の違う人々をできる限り少数にすることで時間を節約できる、異文化交流の連携部分は異文化交流の経験の多い人に任せる
    • 多文化との連携を図る前に大目標を慎重に検討、目標がスピードや効率性なら単一文化のほうがいい

Leading: egalitarian vs. hierarchical / Deciding: consensual vs. top down

  • 組織構造が階層的であることと意思決定のプロセスがトップダウン的かは別
    • 一般的に階層的な組織構造では意思決定もトップダウンだし、フラットな組織構造では意思決定も合意に基づく
  • 日本はかなり特殊で、組織構造は階層的で、意思決定プロセスは合意に基づく
  • これによりできるのが"稟議"で、階層的な合意を効率的に行うシステム
    • 稟議とは、会社・官庁などの組織において、会議の開催により消費する時間を減らすため、担当者が簡易案件を作成して関係者に回し、それぞれに同意のための捺印と承認を求めることをいう。 稟議書 - Wikipedia

  • このような階層的な組織構造かつ、合意に基づく意思決定を行う文化圏(日本)で有効なのが "根回し"
    • 根回し: 公式に合意を確認するための会議の前に、非公式に会合をもって合意を形成しておく

Trusting: task vs. relationship

  • 認知的信頼(trust by task)と感情的信頼(trust by relationship)
  • 例えばアメリカでは2つは完全に分けて考える一方(trust by task)、中国などでは混ぜて考える傾向にある(trust by relationship)
    • アメリカなどで全く感情的信頼が仕事で必要ないかというとそんなことはない、あくまで日本や中国と比べてという話
  • いちど感情的信頼が構築されると、どんな文化的失敗を犯したとしても許してもらいやすくなるので、感情的信頼の構築は重要、問題はどう構築するか
    • 共通の話題をもつ
    • 本当の自分を見せる
    • 本題の前の雑談の時間も文化により異なる

Disagreeing: confrontational vs. avoid confrontation

この本で一番良かった章

  • 自分より対立型の文化の人と会話する場合に気をつけること
    • 自分自身より対立型の文化の人と仕事している場合も見解の相違を表明するのにどこまでが許容される発言でどこからがアウトかはっきりしたニュアンスがわかっていないなら強い言葉の使用には普段よりも注意を払おう。海外とのミーティングで...ドイツ人の取引先に「あなたの提案には完全に反対です」というのはおすすめしない。こうした文化圏では見解の相違は他の文化より率直伝えられるが、だからといってなんでもありというわけではない。ちょっと気を抜くと行き過ぎてしまう。

    • 相手には反論を出させながら、自分にはこれが彼らの積極的な参加の姿勢であり自分個人を批判しているのではないと言い聞かせ、自分が発言する際は無理に相手と同じようなスタイルに合わせる必要はない。もしくは "devil’s advocate" の前置詞をつける (play devil's adovocate とは、日本語で言うなら"あえて意地悪な質問をする(議論をさらに深めて主張を強固なものにするため)"というもの)
    • (以前ドイツからのジョブハンティングのメールに「ありがとう!でもあなたのビジネスに全然興味はないのでお断りさせてください。」と返信して怒らせてしまったことがある。(以前ドイツの会社との面接で相手から笑顔で「これ以上は時間の無駄なのでこれで終わりにしましょう」と言われてこういう感じの発言はセーフなのかと勘違いしてしまったのであった...)
  • 自分より対立回避型の人と会話する場合
    • 日本韓国中国などの儒教的な国では公衆の面前で間違いを指摘されて面子を失い恥をかいてしまうので注意
    • 見解の相違を表明するのにダウングレードした言葉を使う
  • 対立回避型の文化圏で意見を引き出すには?上司がミーティングに参加しない、反論を非人格化する(匿名)slidoで質問を受け付けるなど

Scheduling: structured vs. flexible

  • 文化によってスケジュールへの許容度は異なる
    • 日本は時間に厳しく、インドはゆっくりなど
    • モノクロニックとポリクロニック
  • モノクロニックな文化では時間は触れることのできる具体的なものと考える。スケジュールは生活に秩序を与える分類体系
  • ポリクロニックでは人との関わりや取引の完遂によってスケジューリングを行う。

ヨーロッパの企業に日本からリモートで働くにあたっての手続きまとめ

tanishiking24.hatenablog.com

以前ブログに書いたのですが、3月からポーランドの企業に日本からフルリモートで週3程度で働かせてもらっています。国内では個人事業主として働いているのですが、働き始めるに当たり手続き周りでいろいろ不安なときに、先駆者達の体験談がとても参考になったので知見を共有してみる。

先駆者達のブログ

blog.amagi.dev

tatsumarutimes.com

手続きまわり

契約形態

  • 国内で開業届を出してフリーランス、企業とは業務委託契約を結ぶ形になっています
  • 日本国内に法人がない限り、日本から海外の企業で働くのは個人事業主になるしかないんじゃないかな

給与の受け取り

  • wise のマルチカレンシーアカウントを使うとなんか仕組みはわからないけど外貨の受け取りが可能な口座をシュッと作れて、少ない手数料でいろんな通貨に換金できるらしいのでそれを使った。
    • 口座の開設手続きはアプリ内で完結して、身分確認書類をアップロードして2日くらいで口座開設完了した。
  • どうやら給与は PLN/USD/EUR で受け取れるとのこと
    • PLN で受け取るのが一番いいのかもしれないけど(手数料の関係で)、wise では PLN は受け取れないようだったので、EUR で受け取ることにした。

wise.com


消費税

  • 海外取引は免税なので請求に消費税を上乗せしたりしない。益税もらえないの悲しいね。
  • 個人事業主の給与がすべて海外取引で、取引先に消費税を一切請求していない場合、あえて課税事業者になることによって(経費で発生したぶんの)消費税の還付を受け取れて便利らしい。

www.m-itakura.com


源泉徴収まわり

結局僕の業務は(ポーランド内で?)源泉徴収の対象にはならなかったのだが、ポーランド側で源泉徴収されてかつ日本国内でも所得税を収める必要があるとかなると二重課税されて辛い。

これを防ぐために租税条約というものが各国間で結ばれていて、取引先の会社側の国での源泉徴収が免除されたり減免されたりする。

www.nta.go.jp

租税条約とは?目的や適用例、届出書の手続きなどをわかりやすく解説 | THE OWNER

租税条約の正式名称は「所得に対する租税に関する二重課税の回避及び脱税の防止のための日本国と相手国との間の条約」という。名称が長すぎるため、通常は租税条約という略称が使用されている。

租税条約とは|二重課税を排除するための内容とは|freee税理士検索

租税条約の適用を受けたい時 租税条約では、国際交流促進の観点から、非居住者または外国法人の居住地国又は所在地国とわが国との間で租税条約が締結されている場合には、その租税条約の定めるところにより、その非居住者等が支払を受ける国内源泉所得に対する課税を軽減または免除することとしています。

ただし、この課税の軽減または免除を受けようとする時には、「租税条約に関する届出書」をその国内源泉所得の源泉徴収義務者を経由して、税務署に提出する必要があります。

日本-ポーランドの場合は源泉徴収税の減免

www.jetro.go.jp

Tax Residency Certificate(居住者証明書) を近所の税務署でもらって、それを取引先の企業に提出して完了。


VAT number

そもそも現状の日本の個人事業主には VAT number (ポーランドの場合 NIP) に対応するものは付与されない。

  • 法人の場合は法人番号がそれに対応し
  • インボイス制度の適格請求書発行事業者になると、登録番号がそれに相当する。

僕はまだ適格者じゃないのでそれに相当するものがなかったので、相手先にVAT numberないです〜って言ったらOKということになった。なんとなくマイナンバーだけ提出したけど必要だったのかよく分かってない。

tatsumarutimes.com

VAT number を要求してきたのはインボイス制度と同じように取引先側が仕入れ税額控除的なもののためだと思ってるけどあってるのかな? だとしたらマイナンバーないですで大丈夫なのか、取引先側は余計に税金払う羽目になってたりしない?誰か教えて下さい

biz.moneyforward.com

ぜんぜんわからない。おれたちは雰囲気で税金をやっている

Tests as Documentation

production code の設計についてはよく議論される一方、ユニットテストをどう書くべきかについてはあまり議論されることが少なく。とにかくカバレッジが高ければヨシみたいな感じで軽く扱われていることが多い気がする。

その結果、テストを書くときやとりわけテストを追加するときに "良くない" 方法でテストを追加/拡張してしまい、メンテナンスしにくく壊れやすい・(未来の自分でも)読んでも何を検証しているのか分からない、テストが落ちても不安だけを煽り何が問題なのか分からない、技術的負債が誕生してしまう。

詳しいことは本 ( XUnit Test Patterns など? 詳しい人は僕に紹介してください)を読んだりチームメンバーと議論するのが良いと思うが、この記事を読んでテストの書き方に対する意識を啓発できたらなと思っている。

理想を述べるのは簡単だけど現実は大変、頑張ろう


introduction

ユニットテストの役割のうち最も重要な事のひとつは、書いた・変更したコード(ユニット)が"期待された振る舞い"をすることを検証すること。これに加えて個人的に最も重要な役割だと信じているものが「ドキュメントとしてのユニットテスト」で、xUnit Test Patterns では Communicate Intent と呼ばれる原則として紹介されている。

ユニットテストは理想的には、あるプログラムユニット(関数やクラス)がどういう条件下で・どういう入力に対して・どういう出力を返すか(・またはモックライブラリを使ってどういう挙動をするか)を検証するように書かれており、"良い"ユニットテスト(意図が掴みやすいテスト)は

  • それを読むことでSUT(system under test)の期待する振る舞いの全体像を早く・正確に捉えることができる。
    • (プログラムを一行一行読んだり、更新されてるか(もしくは存在するかも)わからない仕様書と比べて)
  • メンテナンスしやすい
    • 複雑なコードより、わかりやすい簡素なコードのほうがメンテナンスしやすいのと同じですね

そのようなユニットテストを書くために何を気をつけるべきか、何をしないべきか


意図が伝わりやすいテストを書くために

Tests should be easy to write and maintain - Goals of Test Automation によくまとまっている。

Simple Test

テストは小さく、ひとつにつきひとつの条件をテストする Verify One Condition per Test という原則を満たすようにするべき。これによりそのテストが何を検証しているのかが分かりやすくなり、テストが落ちた時に Defect Localization が容易になる。

  • 必ずひとつのテストに一つの assertion にするべきというものではなく、ひとつのテストはひとつの "挙動" を検証するべきというもの。
    • 挙動の検証に複数の assertion が必要なら無理にテストを分割する必要はない
  • また条件と期待する結果の対応がはっきりしているなら Table Driven Testsi などを使うと良いかもしれない。

Expressive Tests

Test Utility Method などを利用して、テストを読むことで何が起きているのか・何を検証しようとしているのか分かりやすいプログラムにしましょうというもの。プロダクションコードに対しては当たり前によく言われていることですね。

Test Utility Method の欠点として、test reader が知るべきAPIが増えてしまうことがありますが、例えば assertContainsExactlyOneLineItem のような Intent Revealing Name を Test Utility Method につけてあげることで、意味の伝わりやすいテストを書くことができる。

Separation of Concerns

  • Keep Test Logic Out of Production Code
    • できる限りテストのために production code に back door のようなものを仕込んだりしないようにしましょう
    • テストとは、システムの挙動を検証するもので、テスト中にシステムの挙動が変わってしまっているのなら、production code をテストしていることにはならない。
  • Test Concerns Separately
    • 例えば(ユニットテストで)UIのテストの中でビジネスロジックをテストしてはいけない。
      • テスト対象の関係性が変更されるたびに、テストが壊れてしまう(ビジネスロジックの変更によりUIのテストが壊れるなど)。これにより、何が原因でテストが壊れたのか問題を分離することが難しくなる。
      • 簡単なように思えるが、システムが複雑で返ってきた値を何でもかんでもassertしているといつの間にか依存モジュールの挙動に左右されるテストが出来上がってしまうことは往々にしてある。SUTが真に成し遂げようとしている振る舞いを分析して最小限のテストを頑張って書こう。難しいけど。
    • うまく Test Double を使いましょう

アンチパターン

上の項と多少内容が重複するが、xUnit Test Patterns では(意図や挙動が)分かりにくいテストのことを Obscure Test と読んでいて、そのいくつかの原因に関する考察が紹介されている。

Eager Test

  • とにかく一つのテストで何でもかんでも assert しまくってしまっているテスト
  • Verify One Condition per Test 原則に従いましょう

Mystery Guest

  • 暗黙的な事前条件(test reader が気づくことができない条件)がテストの結果に影響しているおり、テストを読んでもどういう条件下でその出力が得られるのか分かりにくい状態
  • 例えば、外部ファイル・他のテストなどによって追加されるDBのデータ・ランダムに生成されたデータ
    • fake dataに意図せずテストが依存してしまうことはよくあるし気づきにくい。個人的にはfake dataの利用は局所的にしていきたいと思っている(例えばテストデータのオブジェクトそのものを生成するのではなく、オブジェクトのうち関心のないフィールドに対してだけ利用するなど)

General Fixture

  • ひとつの Shared Fixture がtoo manyテストのために働いている状態
  • Mystery Guest と同じように、巨大な Shared Fixture が設定したデータにテストが依存しており test reader がテストを読んでもどういう条件下でその出力が得られるのか分かりにくい状態
  • Test fixture は Minimal Fixture を目指すべき

Irrelevant Information

  • テストの入出力に、SUTの挙動に関係のないデータが大量に記述されている状態
  • SUT の動作に本当に影響を与えるものがどれか分かりにくい、どのassertionがこのSUTが満たすべき振る舞いを検証しているのか分かりにくい
  • constructor や factory method への直接呼び出しを、関連情報のみをパラメータとするCreation Methodの呼び出しに置き換えよう
    • テストにとって重要でない値は、Creation Methods の中でデフォルト化 or ダミーオブジェクトに置き換えて隠蔽する。こうすることで、test reader に対して「表示されない値は、期待される結果には影響しません」と伝えることができる。

Hard-Coded Test Data

例えば以下の例では、30 とか 19.9 のような hard coded された数字を入力し、結果として 69.96 などの値を期待しているが、これが何を意図した値なのかが分からない (69.96 はどこから来たんだ?)

we might still miss the relationship between the unit price (19.99), the item quantity (5), the discount (30%) and the total price (69.96.)

   public void testAddItemQuantity_severalQuantity_v12(){
      //  Setup Fixture
      Customer cust = createACustomer(new BigDecimal("30"));
      Product prod = createAProduct(new BigDecimal("19.99"));
      Invoice invoice = createInvoice(cust);
      // Exercise SUT
      invoice.addItemQuantity(prod, 5);
      // Verify Outcome
      LineItem expected = new LineItem(invoice, prod, 5,
            new BigDecimal("30"), new BigDecimal("69.96"));
      assertContainsExactlyOneLineItem(invoice, expected);
   }

http://xunitpatterns.com/Obscure%20Test.html から引用

意味が伝わりやすい定数にしてあげたり、無関係な値は Creation Method によって隠蔽してあげるなどしましょう。

Indirect Testing

  • プレゼンテーション層などの中間オブジェクトを通してビジネスロジック(SUT)をテストすることなど
  • 中間オブジェクトを通してSUTの挙動を観察することになるので、入出力が複雑になり分かりにくい。
  • 原因としては product code がテストしにくい設計になっている可能性が高い。

参考