You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
概要 dockertest は go でテストを書く際に docker 経由で指定したコンテナを起動してくれてテストが終わったらコンテナを削除してくれる便利ライブラリです。 モチベーション 時雨堂では TimescaleDB という PostgreSQL に TSDB 拡張を追加した少し変わった RDBMS を利用しています。 TimescaleDB 専用の関数があったりするため、モックなどを使わずにテストを書くのが現実的です。 dockertest ory/dockertest: Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal work. 基本的には dockertest の README に書いてある内容を
Goでテーブル駆動テストを書いていると、書いているときは「すげー読みやすくテスト書けてるぞ!」と思っていても、落ち着いてから見てみると「なんだこれ...訳がわからん...」となることがあると思います。(自分はよくあります。) この記事は、このようなことを解決するのに役立つtipsについてまとめています。主にテストケースについて焦点を当てています。 テストしやすいコード設計に興味がある方は や を参考にしてください。 はじめに この記事はパーソナライズGopher道場で学んだことを元に書いています。 そして、この記事で紹介するテーブル駆動テストの書き方は主観に基づいており、 あくまでテストの1つの書き方にすぎないです。 なので、「この書き方をしないとダメ!」というものではないので、みなさんの考え方やプロダクトに合わせて、柔軟にこの記事で紹介するtipsを取り入れていただけると幸いです。 結論
CircleCIにはJUnit形式のテストレポートを食わせてテスト結果をわかりやすく表示してくれる機能があるのですが、GitHub Actionsでも同じようなことができないかなと思って調べてみたところ、以下のアクションを使えばできそうなので試してみました。 github.com 使い方は簡単で、テスト実行後にこんな感じの設定を追加するだけ。 - name: Publish Test Report uses: mikepenz/action-junit-report@v2 if: always() with: report_paths: '**/build/test-results/test/TEST-*.xml' Scalaプロジェクトの場合、sbtがtarget/test-reportsディレクトリ配下にJUnit形式のテストレポートを出力してくれるのでreport_pathsを以下の
Rubyでテストがこれほど盛んな理由のひとつはRailsの存在にあると私は信じています。Railsフレームワークはテストをできる限り楽しく書けるようにしてくれます。ほとんどの場合、網羅的なRailsテスティングガイドを参照すれば事足ります(少なくとも最初のうちは)。しかし物事に例外はつきものです。私たちの場合「システムテスト」がそれでした。 テストをページのマークアップから切り離す方法については、「Railsシステムテスト」シリーズの次の記事『System of a test II: Robust Rails browser testing with SitePrism』をご覧ください。 Railsアプリケーションでシステムテストを書いたりメンテしたりするのは、正直「楽しい」からほど遠い作業です。この問題に対処するために用いた私のアプローチは、今を去ること2013年に初めてCucumber
ソフトウェアテスト Advent Calendar 2016 - Qiitaの9日目エントリーです。 qiita.com エラーが「自動的に」増殖するのがDevOps To make error is human. To propagate error to all server in automatic way is #devops.— DevOps Borat (@DEVOPS_BORAT) 2011年2月26日 継続的デリバリーの核心は、フィードバックのサイクルを素早く回すことにありますが、それはユニットテストのカバレッジが十分になければ不可能です。 A/Bテスト、オートスケール、カナリヤテスト、Blue-Green Deploymentなど、DevOpsを推進する上での各種プラクティスは、いずれも、プロダクトの品質が安定していることを前提としています。品質が安定していない状態でリリ
ScalaTestでMockitoを使うためのお勉強ノート Setup build.sbt に追加。 libraryDependencies ++= Seq( "org.scalatest" %% "scalatest" % "1.9.1" % "test", "org.mockito" % "mockito-core" % "1.9.5" % "test" ) テストで MockitoSugar を mixin し、以下の import 行を追加。 import org.mockito.Matchers._ import org.mockito.Mockito._ Mock作成 // ClassToMock のモックを作成 val m = mock[ClassToMock] 作ったモックはデフォルトで全メソッドコールに対して null を返す。 メソッドの戻り値としてnullではなくモッ
2011-09-18 / sbt NOTE: Official docs: http://www.scala-sbt.org/1.x/docs/Testing-sbt-plugins.html Let’s talk about testing. Once you write a plugin, it turns into a long-term thing. To keep adding new features (or to keep fixing bugs), writing tests makes sense. But how does one go about testing a plugin to a build tool? We fly, of course. scripted test framework sbt comes with scripted test framew
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く