テストを書くときに気をつけていること - m_nakamura145’s diary
この記事はトレタ Advent Calendar 2016の8日目です。 それなりの規模のサービスだとテストを書くと思う。 テストコードはテストデータの準備なども含めると、コード量が多くなりやすい。そのため、読みやすく意図が通じやすいテストを書くように意識しないと初めてテストコードを読む人が理解し辛い。 テストを書くときに考えていることを言語化して他の人と議論したことが無かったため、今回のエントリでは普段自分が気をつけていることについて書いてみる。 例として、予約を更新する PUT /reservations/:id について述べる。リクエストを受け取ったらJSONを返すAPIとする。 describe "ReservationsController" do describe "PUT /reservations/:id" do let(:reservation) do FactoryGi
プログラマーも手動テストしようぜ 〜 忍者式テストのすすめ 〜 - Qiita
はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が
（C++）constexpr & static_assertによるコンパイル時テストの用途 - 千里霧中
これは ソフトウェアテスト Advent Calendar 2016 - Qiita の4日目の記事です。 C++では、C++11から以下の言語仕様が追加されました。 ・違反するとコンパイルを失敗させる表明構文：static_assert ・指定対象をコンパイル時に処理させる指定子：constexpr このstatic_assertとconstexprを組み合わせると、コンパイル時テストを柔軟に構築できるようになります。 コンパイル時テストは、コンパイルの際に実行され、テストに失敗したらコンパイルエラーを発生させるものです。これはC++のようなコンパイラ方式言語で、テストの選択肢を広げる助けとなります。今回は組み込み向けを想定して、コンパイル時テストの用途を紹介したいと思います。 コンパイル時テストの用途１：コンパイル時処理のテスト constexprで記述されたコンパイル時処理なら、大抵
DockerとSeleniumGridとNightwatchでE2Eテストを始めよう - 文系プログラマによるTIPSブログ
Dockerで簡単に始められますよ〜 Nightwatchならライトにサクッと書けますよ〜 皆さんはE2E(end to end)テスト、してますか？ 今回はDocker、Selenium grid、Nightwatchを使ったE2Eテスト（ブラウザテスト）の環境構築からテスト実行、VNCでテスト実行の様子を確認するところまでやってみようと思います。 技術要素 なぜNightwatchなのか 環境構築 docker node.js for mac for windows テストの準備 dockerコンテナ git clone node_moduleの依存 nightwatchの設定 docker-hub Nightwatchでテストを実行する ローカルでテストする場合 Selenium Gridで並列テストする場合 dockerコンテナの起動 Selenium Gridの動作確認 Nigh
Aruba gemでCLIのテストを支援する - Qiita
Aruba とは？ ArubaはCucumber、RSpec、Minitestのような人気のあるTDD/BDDフレームワークで コマンドラインアプリケーションのテストを簡単で楽しいものにする拡張です。 cucumber/aruba - GitHub 特徴 どんな言語で実装されたコマンドラインツールでもテスト可能 テスト自体はRubyで書くが、テスト対象は Python の CLI ツールでも Golang の CLI ツールでもよい ファイルシステムやプロセス環境をヘルパーによって操作できる 例えば read でファイルを読み込みできる 例えば run で外部コマンドを実行し、その結果を have_output matcher などで検証できる ファイルシステムやプロセス環境はテストのたびにリセットされるので、 leaking state がない 例えばテスト中に作成されたファイルはテスト
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
go言語のコンストラクタでinterfaceを返す | さにあらず
go 言語において呼び出し元に interface のみを公開することで実装の詳細を隠ぺいすると、gomock を使ったテストがやり易くなります。 ざっくり結論だけ書くとこんな感じのコーディングパターンにすると良いよって感じなので、これだけ見て、何が言いたいのかすぐに分かる人は続きを読まなくても良いと思います。 package intf type Duck interface { Quack() string} type duck struct {} func NewDuck() Duck { return &duck{}} func (d *duck) Quack() string { return "QUUAAAACCCCKK!!!"}コピー interface と実装が分離されたアヒル#最初のポイントは、公開する interface として定義された Duck と非公開の struc
ElmでHTMLパーサを作って公開するまでの手順 - ジンジャー研究室
ElmでHTMLパーサを作った。 github.com せっかくなので、ライブラリ制作に着手してから公開するまでのプロセスを書いてみる。Elm 開発の雰囲気を伝えるのが目的なので、特定のトピックが知りたい方はQiitaへどうぞ。（コードが沢山あるけど試してないので動かないかも。あと、途中でテストライブラリをアップデートしたりして実際に踏んだプロセスと違うし、コードも所々違うんだけど、それは無視して最短・最適のパスを踏んだことにする。） 経緯 Excel（とか他の表計算ソフト）からクリップボードにコピーしてWebアプリに貼り付けようとしたところ、フォーマットがHTMLだったのでパースしてデータを取り出したかった。ここで問題発生。 ElmにHTMLパーサが無いだと。。— Yosuke Torii / ジンジャー (@jinjor) August 30, 2016 別にJSでパースしてElm側に
Ansible向けのコードカバレッジツールKirbyを作りました - Soon Lazy
PythonやJavaでコードを書く場合、コードカバレッジの測定は、よくやりますよね。最近、Ansibleでもコードカバレッジを測りたくなったのですが、それらしいツールがなかったので、作ってみました。名前はKirbyです。今回はKirbyがどんなツールなのか紹介してみます。 ks888/kirby · GitHub どんなことができるのか Kirbyは、AnsibleのPlaybookやRoleに対して、タスクレベルのカバレッジを測定するツールです。 例えば、次のようなPlaybookと、Serverspecのテストがあったとします。Playbookでは2つのタスクを実行しています。Serverspecのテストでは、Playbookの一つ目のタスク（create dir1）に対するテストをしています。 ~/src/kirby_demo% cat create_2dirs.yml --- -
Jest 15.0: New Defaults for Jest · Jest
We spent the past year making Jest faster, easier to configure, added tons of features and built snapshot testing. However, there were two areas where we invested very little: the CLI output and user experience. With Jest 15 we are changing the framework radically to make it easier to use both for beginners and experienced users. We are excited that our investment in Jest is now paying off: we can
Go - Web Application周りのテスト方法 - Qiita
package main import ( "net/http" "github.com/facebookgo/grace/gracehttp" "github.com/sebest/xff" "goji.io" "goji.io/pat" "golang.org/x/net/context" ) func main() { mux := goji.NewMux() mux.HandleC(pat.New("/*"), NewMux()) err := gracehttp.Serve(&http.Server{Addr: ":8080", Handler: mux}) if err != nil { panic(err) } } func NewMux() *goji.Mux { mux := goji.NewMux() mux.Use(xff.Handler) mux.HandleFun
モックライブラリ・Prophecyの使い方まとめ - Qiita
Prophecyとは phpspec/prophecy PHPUnitと組み合わせて使えるモックライブラリ。 元はphpspecの一部として開発されたもので、phpspecと組み合わせなくても単独で使うことができる。 PHPUnit 4.5からパッケージに同梱されるようになった。PHPUnitの新しいバージョンを使っていれば、composer.jsonに加えなくても使うことができる。 テストダブルとは ユニットテストを書くときに、テスト対象の依存の代替として使うオブジェクトをテストダブルと言う。目的はいくつかある。 依存オブジェクトの準備を手抜きする。100行の準備をしないとテストが書けないとしたらユニットテストが読みにくくなってしまう。 実行しづらいメソッドを差し替える。外部へ通信してしまうもの、I/Oが発生するもの、すごーくたまにしか失敗しないものなどを強制的に変更したいとき。 メソッ
テストツールを利用したmrbgemの作り方 - Qiita
始めに mrubyではmrbgemを利用して機能の追加が容易にできます。Cで書かれたライブラリであれば、インタフェースを定義する事でその機能をmrubyに組込めます。現在では多くのライブラリがmrbgemとして公開され、mrubyを試すハードルは低くなりました。 しかし、小規模なマイコンをターゲットにする場合、そもそも規模が大き過ぎるなど要求に適したライブラリがなく自作する事はしばしばあります。リソースの小さなマイコンであればライブラリそのものがなく、ハードウエア依存の箇所が多くなると同じく自作を選ぶ事になります。 それならばmrubyを組込むよりも全てをCで書いた方が容易だと感じられるかもしれません。しかし、ライブラリ作成とはC向けのAPIを提供する事と同義です。そしてmrubyはC向けのAPIを取り込む仕組みがあります。Cとmrubyの両方をターゲットとするライブラリとしてmrbgem
外部APIを使うController用のTest Doubleライブラリを書いた - Qiita
Goで net/http を使ったControllerのテストには、 net/http/httptest モジュールを使うと擬似的にサーバをその場で立て、登録したハンドラにリクエストを送れます。 ただ、APIに使うアクションはたびたび、外部のAPIを叩くこともあります。 その際、テストを実行するときに外部APIを使えない状況(本番環境とは違う状況、例えば、production用のAPIの発行には金銭が発生するなど)に遭遇します。 そんなときに知られているテクニックとして、テスト時に外部APIへのリクエストをDouble(Stub)することです。 その外部APIが返却するであろう期待値を登録しておけば正常ケースを、エラー値を登録しておけばエラーケースをテストできます。 ここで例に挙げるStubする方法は、 http.Client をもとにHTTPリクエストすることを前提としています。 ではど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - istanbuljs/babel-plugin-istanbul: A babel plugin that adds istanbul instrumentation to ES6 code
GitHub - DevExpress/testcafe: A Node.js tool to automate end-to-end web testing.
GitHub - khanghoang/vision: Mock request on the flight
GitHub - douglasduteil/isparta: :skull: A code coverage tool for ES6 (babel/6to5)
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
BugHunt・1時間から頼めるシステムの品質チェック
