開発効率を上げるテスト設計#phpblt6 ソースコード https://github.com/kazu9su/phpblt-6-example
受け入れテストの自動化 ～ OpenCVの「眼」で捉え、Pythonの「脳」が思考し、Appiumの「指」で動かす - Speaker Deck
2017/02/03 JaSST’17 Tokyo
よいユニットテストを書くには
テストを小さくする。適切なツールを使う。プログラマとテストがペアになる。これらは、よいユニットテストを書くための、Adrian Bolboaca氏からの提案だ。 ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。 Adrian Bolboaca氏は、Mozaic Worksの組織と技術に関するコーチであり、ヨーロッパテストカンファレンス 2017において、様々なタイプの自動テストについて話す予定だ。 InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。 [ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。 私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十
DevOps時代のテスト要求分析 - Test Automation
はじめに こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。 qiita.com ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。 DevOps時代のテスト要求分析は難しい DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。 （理由１）ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する （理由２）開発中にシステムのアーキテクチャ設計が変化する このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性に
テストしやすいGoコードのデザイン
テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency
[検証中]更新のあったファイルだけgo testを走らせテストを高速化する #golang #gae - Qiita
はじめに go test（GAE/Goの場合はgoapp test）で、自身のプロジェクトのテストを走らせる際、非常に時間がかかってしまいテストの実行が億劫になることがあります。 特にGAEだとaetestパッケージを使わなくてもそれなりに時間がかかります。 GAE/Goのテストを早くするには、favclip/testeratorを使ってインスタンスを使いまわすという方法もあります。 しかしながら、それでもそれなりに時間がかかるので、どうにか更新のあったソースコードに関わるテストだけ実行できないかと考えました。 なお、この記事ではgitなどを使ってバージョン管理している前提で書いています。 また、おそらくちゃんと動くだろうとは思いますが、まだ検証中なのでデプロイする前には、ちゃんとすべてのテストを実行することをオススメします。 coverprofileを使う go testのオプションには
![[検証中]更新のあったファイルだけgo testを走らせテストを高速化する #golang #gae - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/24f0d7b11697e587165a1cf24719b832ca431f8b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU2JUE0JTlDJUU4JUE4JUJDJUU0JUI4JUFEJTVEJUU2JTlCJUI0JUU2JTk2JUIwJUUzJTgxJUFFJUUzJTgxJTgyJUUzJTgxJUEzJUUzJTgxJTlGJUUzJTgzJTk1JUUzJTgyJUExJUUzJTgyJUE0JUUzJTgzJUFCJUUzJTgxJUEwJUUzJTgxJTkxZ28lMjB0ZXN0JUUzJTgyJTkyJUU4JUI1JUIwJUUzJTgyJTg5JUUzJTgxJTlCJUUzJTgzJTg2JUUzJTgyJUI5JUUzJTgzJTg4JUUzJTgyJTkyJUU5JUFCJTk4JUU5JTgwJTlGJUU1JThDJTk2JUUzJTgxJTk5JUUzJTgyJThCJTIwJTIzZ29sYW5nJTIwJTIzZ2FlJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0wNjYzN2IxNmIwODdhMmI2MDk3OThjNjc3YTJjNWNjNQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0ZW5udGVubiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZjJkMmQ3ZTEwOWJlMWZjMmJlYjc1NTJlYTcyNTg5MDY%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gTWVyY2FyaQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D42ac9bff8c3dc8e00a7fac5daafd72f9)
Big Sky :: golang で終了を確認するテストの書き方
いい記事に感化されて僕も何か書きたくなった。 Golangにおけるinterfaceをつかったテスト技法 | SOTA Golangにおけるinterfaceをつかったテスト技法 最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単... http://deeeet.com/writing/2016/10/25/go-interface-testing/ 僕も1つ golang のテストの tips を。golang を書いていて良くあるのが「コマンドがステータス 0 で終了する事」のテスト。 package main import "os" func doSomething() { os.Exit(0) } func main() { doSomething() } でも os.Exit しちゃうとテ
Golangにおけるinterfaceをつかったテスト技法 | SOTA
最近何度か聞かれたので自分がGolangでCLIツールやAPIサーバーを書くときに実践してるinterfaceを使ったテスト技法について簡単に書いておく．まずはinterfaceを使ったテストの基本について説明し次に自分が実践している簡単なテクニックをいくつか紹介する． なおGolangのテストの基本については @suzuken さんによる「みんなのGo言語」 の6章が最高なので今すぐ買ってくれ！ 前提 自分はテストフレームワークや外部ツールは全く使わない．標準のtestingパッケージのみを使う．https://golang.org/doc/faq#Packages_Testing にも書かれているようにテストのためのフレームワークを使うことは新たなMini language（DSL）を導入することと変わらない．最初にそれを書く人は楽になるかもしれないが新しくプロジェクトに参入してきたひ
Golangにおけるinterfaceをつかったテストで mock を書く技法 - haya14busa
いい記事に感化されて僕も何か書きたくなった。 Golangにおけるinterfaceをつかったテスト技法 | SOTA リスペクト: Big Sky :: golang で終了を確認するテストの書き方 GolangでAPI Clientを実装する | SOTA Big Sky :: GolangでAPI Clientを実装する、の続き 今週のやつではなく先週のです．今週のは特に知見がなかった…grpc-goとか使えたらクライアント勝手に生成されるしいいよねgrpc流行ると便利そう(感想) くらい Golangにおけるinterfaceをつかったテスト技法 | SOTA めっちゃいいなーと思ったんですが，テスト用 の mock を気軽に作るテクニックはあまり詳しく紹介されてなかったのでそのあたりの１つのテクニックを書きたい． 前提 僕もテストフレームワークや外部ツールは全く使わない．標準のt
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
QAアーキテクチャの設計による�説明責任の高いテスト・品質保証
1. © NISHI, Yasuharu QAアーキテクチャの設計による 説明責任の高いテスト・品質保証 Vector Testing User Day 2016/10/24（月） 電気通信大学 大学院情報理工学研究科 情報学専攻 経営・社会情報学プログラム 西 康晴（Yasuharu.Nishi@uec.ac.jp） 2. © NISHI, Yasuharu2 Profile Assistant professor: the University of Electro-Communications, Tokyo, Japan General chair: IEEE International Conference on Software Testing 2017 Tokyo (ICST 2017 Tokyo) 2017/3にGoogleからテスト自動化の基調講演/NASA&ESA&JAX
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
Android/iOSアプリのテストの区分戦略 - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 クックパッドのモバイルアプリ開発では、どのようなテストを書き、どのようなタイミングで、どのようなテストを実施するか？に関してエンジニア各位が意識を合わせるためにテストサイズを定義し運用してきました。ここでは、そんなテストサイズに関して簡単ですがまとめておこうと思います。 テストサイズとは ソフトウェアテストに関わったことがある方なら テストレベル という言葉には出会ったことがあるかと思います。JSTQBでは、このテストレベルは"管理していくテストの活動のグループ"と定義しています*1。 そうでない方も、俗に言う単体テスト/統合テストなど聞いたことがあるかと思いますが、その区分がここで示しているテストレベルとなります。 一方、このテストレベルはV字型と言われる開発工程と合わせて世の中で広く使われているため、社内における共通認識を構築するにあたり個
実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ
技術部の taiki45 です。 以前「サービス分割時の複雑性に対処する: テスト戦略の話」という記事で、サービス間のインテグレーションテストにおける問題について紹介しました。現在のクックパッドではこの問題の解決のために Pact というツールを導入して運用しています。この記事では、その運用の知見を紹介できればと思います。 Pact Pact は Consumer-Driven Contract testing (CDC testing) を実現するためのツールです。"Consumer"、"Provider" という見慣れない単語が出てきますが、この記事ではだいたい「Consumer = Web API クライアント」、「Provider = Web API サーバー」と対応ができます。この記事では具体的な Pact の利用例を通じて CDC testing がどういうものなのかについても
net/httptestでgojiのテストをする - Qiita
goji でWebアプリを書こうとしています。APIサーバーとして使うときに、テストが気になります。 golangは net/http/httptest というhttpのtestを行うパッケージが最初からついています。これを使うと簡単にテストを記述できます。 httptest.Serverはlocalのloopbackインタフェースでサーバーを作成します。 (2014/11/20追記): mopemopeさんから「Routingのテストを入れたほうがいいのでは」というご指摘を受けたので、Route設定を別関数に分け、テストからも使うようにしました。 サンプルアプリ /hello/hoge というURLにアクセスが来たらJSONを返す、という単純なアプリです。 package main import ( "encoding/json" "fmt" "net/http" "github.com
"shove" というシェルスクリプト用のテストツールを作った - weblog of key_amb
CONTENTS: "shove" とは Motivation こんなツールにしたい 使い方について 中で何をやっているのか おわりに "shove" とは こちらです。 github.com 動作イメージとしては README.md にも貼っているスクリーンショットがわかりやすいと思うので、こちらにも貼ります。 成功時: 失敗時: 上のようにテストスクリプトを引数に与えて shove コマンドを実行すると、テストを実行して結果を出力してくれます。 Perl Monger のみなさんは「proveっぽい」と思っていただけたでしょうか。 そうです。名前の "shove" は "shell" + "prove" を縮めたものです。 bash だけでなく、ksh, dash, zsh など POSIX を満たしているシェルに対応できるように作りました。 $SHELL 変数の値と異なるシェルでテス
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
wip-testable-js.md
g.o.a.t - 縦書き可能なブログサービス
わたしたちの開発現場
