ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
その例外、いつキャッチするの？
はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と
Docker Desktopの代替方法 - Windows and Mac編
はじめに 新方針でDocker Desktopが大企業での利用の場合は商用ライセンスの使用が必要になるようです。新料金体系は8/31から実施ですが、2022年1月31日まで猶予期間があります。 個人やスモールビジネス、あるいは教育やOSSプロダクトなどは継続して無料版のPersonalを利用できるようですが、従業員数250人以上/年間売り上げ10億円以上の会社が対象になるようです。今見てる限りだと部署とかチームみたいな契約の単位では無く会社規模なので、大きな組織に所属してるともれなく対象になりそうですね。 $5/userからなので基本的には運用性も含めて払う方が楽だと思いますが、金額の大小にかかわらず予算を取るのが大変な組織や会社自体はデカくても部署がインキュベーションなので予算が基本無い、とか色んなパターンもあるかと思います。 ちょうど、手元のPCでここ最近 Docker Desktop
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
ふつうのユニットテストのための７つのルール
はじめに 「テストが大事」 これは生産性と品質を高めるための基本的な考え方です。なので 「テスト書かないと」 ってことはみんな同意するのでUnitTestらしきものが書かれてることは多いのですが、役に立たなかったりむしろ有害ですらあるテストがあふれているプロジェクトもあります。作った人に罪は無いのですが、頑張ったのに悪い方向に行ってしまうのはもったいない これはユニットテストを有効活用するための最低限のルールが守られてないためです。あまり学校で習う類のものでもないかもしれないですし、大事だと思うので個人的な見解をまとめておきました。 ポータビリティを大事にする 繰り返し実行できるように作る Unit Testですべての自動テストをしない モックやスタブを過度に使わない ひとつのテストケースにはひとつの観点しか検証しない テスト内容が分かる名前をつける ログや標準出力は極力出さない Java
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
