ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
テスト用に、外にメールを送らないメールサーバをつくろう - お前の血は何色だ!! 4
あなたのアプリケーションでは、電子メールを使っていますか？ Yesであれば、どうやってデバッグしていますか？ 電子メール送信は rollback できない処理の一つだと思います。 間違ってテストのデータをお客さんに送信してしまった!! って日にはひたすら謝るしかありません。。。 もちろん、プログラム側での工夫だったり、あらかじめメールアドレスを塗りつぶしたデータを使うなどの予防策を講じれば、ご送信をある程度は防げますが、、、、もっとシステムチックな誤送信対策はないでしょうか。 と、いうことで、 prostfix と sendmail で外部にメールを送信しない smtp サーバをつくろうってわけです。 すべてのメールアドレスをたたき落としてしまうと、検証が非常に難しくなるため、ここでは、 自社とパートナーのドメインだけは通過させ、それ以外は叩き落すというようなルールにしてみたいと思います。
QAエンジニア - Qiita
概要 この数年 「QA(Quality Assurance)エンジニア職」 という職種が重要視されております。 所謂、品質保証です。 振り返ると2000年代は、求人自体も少なかった職種ですが、昨今はIndeedやスタンバイなどの求人情報専門の検索エンジンで 「QAエンジニア」 「テストエンジニア」 「品質管理エンジニア」 で検索すると大企業からスタートアップまで多くの掲載求人がヒット・掲載されています。 最近は、企画段階から 「QAエンジニア」 が参加し、プロダクトUI・UXの意見交換や、仕様書レビュー、テストフロー、プロダクトリリース判定基準、どのテストレベルを対象とするか策定する。 そのため、QA職種だからこの範囲（領域）だけという決まりはありません。 また、QA職種詳細については 「品質担当でも名称がいろいろ」 に記載しております。 「QAエンジニア」 って、そもそもどのような役割な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
