タグ

テストに関するhiroyukimのブックマーク (13)

  • golangでABテストの振る舞いを実装する - at kaneshin

    golangに限らないんですが、ABテストの振る舞いをちゃんとした設計のもと実装するのって難しいと思っています。 よくあるパターンとしては、Userという構造体があって、それに対してABテストによる振る舞いを変えるように実装をすることかと思います。 User type User struct { ID int Name string } 関数を生やす あまり考えずに関数を作っていく方針 func (u User) IsFoo() bool { return u.ID%10 == 0 } func (u User) IsBar() bool { return u.ID%10 == 1 } func main() { u := User{ID: 1, Name: "kaneshin"} fmt.Println(u.IsFoo()) fmt.Println(u.IsBar()) } コード:ht

    golangでABテストの振る舞いを実装する - at kaneshin
  • テスト全体の良い書き方について。 #swtest_jp - うさぎ組

    概要 テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。(実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基はこの形であり、ここにある考え方が重要だと思っています。 つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。 僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。 まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。 構成のテンプレ 基的に3段

    テスト全体の良い書き方について。 #swtest_jp - うさぎ組
  • Javaのユニットテスト・ライブラリ・ツールまとめ - Qiita

    #テストの必要性 以前のシステム開発と言えば、ウォーターフォールのような要件から設計、実装、テストのような徐々に作業を細分化し最後にテストを行う手法が主流、というかSierとかでは基今でもこの手法が多いはず。 しかし、現在はアジャイル開発の普及にともない、TDD、BDDに代表されるようなテスト重視の開発スタイルが増加している。 その中で実際テストコードを書いてみようとすると、Javaではテストフレームワークやツール、ライブラリ等が多数あり、どれを選択すべきか悩みどころになってくる。 ここではそれらを整理するため、Javaのテストコードを書くときに必要な情報をまとめておきます。 #どれを使うか・・・ 個人的には、どれを使いうかと考えた時に以下に注意している。 簡単、シンプル テストコードをするために、時間がかかり過ぎたり、可読性が低下したり、ロジックがあまり複雑になるようなものは避ける。

    Javaのユニットテスト・ライブラリ・ツールまとめ - Qiita
  • イチから分かる、テスト自動化とSelenium | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム

    今日は、テスト自動化と、ブラウザ自動テストツールSeleniumについて、知らない方でも分かるようイチから解説したスライドを作ったのでご紹介します。 このスライドは、2014年2月28日に開催された「Enterprise × HTML5 Conference」の発表スライドに、時間の関係で省略した多数の未発表ページを加えたものです。 イチから分かる解説についてはこれで終わりですが、せっかくですのでスライドの見どころをご紹介しましょう。

    イチから分かる、テスト自動化とSelenium | MagicPod Tech Blog | MagicPod: AIテスト自動化プラットフォーム
  • WebのUIテスト自動化 - Seleniumを使ってみる - Qiita

    Appiumを色々触っているんですが、仕組みが同じSeleniumもちょっと触ってみました。 だいぶ色々なことができそうなのでこちらも触りつつメモを取っていこうと思います。 実際の動画デモ 実際にどんなことができるのか、参考動画を撮ってみました。 内容的にはネタな感じにしていますが、どんなことができるか分かってもらえるかと思いますw Seleniumとは Seleniumはクロスブラウザ、クロスプラットフォームのUIテストツールです。 ブラウザに表示される要素を操作し、取得して想定されうる状態になっているかをテストできます。 また、画面のキャプチャを撮ることもできます。 検索してみると有用な記事がいくつかあるので、詳細はそちらを見てください。 ここでは簡単に触ったメモや所感を書いていきます。 JavaScriptテスト自動化ツールSeleniumのこれまでとこれから(前編)。第1回 日S

    WebのUIテスト自動化 - Seleniumを使ってみる - Qiita
  • bitbucketの使い方

    With best-in-class Jira integration, and built-in CI/CD, Bitbucket Cloud is the native Git tool in Atlassian’s Open DevOps solution. Join millions of developers who choose to build on Bitbucket.

    bitbucketの使い方
  • これからGAIQの取得、受験をお考えの方へ - ムラウェブドットネット

    3月末にGoogleアナリティクスの認定試験であるGAIQを取得いたしました。 GAIQの受験は初めてだったのですが、なんとか合格することができました。 今後、爆発的にGAIQを受験する人が増えるとは思えませんが、これからはじめての受験を考えてる方に、自分が感じた戸惑いや攻略法を記載いたします。意外と長文となってしまいましたが、何かのお役に立てればいいなと思います。 GAIQ受験メモ ・問題はすべて英語 Googleで提供されている他の試験は、英語以外の言語でも用意されているようですが、GAIQでは日語版を用意されていません。問題、答え、試験説明、結果と受験に関するすべてのものは英語となります。 ・翻訳ツール(サイト)が使えない 英語が必ずしも得意ではない私は、Google翻訳やエキサイト翻訳をバリバリ使おうともくろんで試験を開始したのですが、それらの翻訳サイトやツールを利用することがで

  • 第17回 QuickCheckでデータ駆動型テストを行う

    テストには常にある種の不安が残ります。このテストは果たしてすべての場合に妥当だと言えるのか? 何か見落としてはいないか? その見落としは致命的なものではないか? Haskellの静的な型検査をすり抜けてくるバグに対処するには,実際にプログラムを動作させ,HUnitなどで動的なテストを行います。では,動的なテストをすり抜けるバグにはどう対処すればいいでしょうか? 一番単純な対策は,テスト項目数を増やすことです。たいていの場合,テスト項目は「その型の取りうる値を想像し,その例に対してきちんと動作するかどうかを確かめる」という形で記述します。単純に考えるなら,テスト項目が増えれば増えるほどテストの正確さは増していくはずです。 しかし,個々の値に対してテストを記述していくのは手間のかかる作業です。テストを行うべき値の集合に対してテストを行うツールが欲しくなりますね。それが「データ駆動型のテスト・ツ

    第17回 QuickCheckでデータ駆動型テストを行う
  • データベースのテストの話 - tsucchi’s diary(元はてなダイアリー)

    最近のお仕事の話とかデータベースのテストってみんなどうやってるんだろ?の続きみたいな話。 マーチン・ファウラーが Thought Works における、Ruby での開発について色々書いてます。(記事が書かれてすぐ邦訳されてた。ありがたやありがたや。) で、全編通して面白い記事なのですが、特に興味深かったのが下記のくだり。ちょっと長いけど引用します。 Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby - Active Recordのテスティング Active Recordの問題は、データベースアクセスコードをビジネスロジックと一緒にしてしまっていることだ。これでは、データベースダブルを作ることが難しい。 Mingleチームでは、Railsがデータベースと密接に結びついていることを受け入れ、物のデータベースに対してすべてのコミット

    データベースのテストの話 - tsucchi’s diary(元はてなダイアリー)
  • Dockerを使ってJenkinsのジョブごとにテスト実行環境を分離する - orangain flavor

    はじめに JenkinsでJVM上で動かない言語(PythonRubyなど*1)を使っていると、ジョブごとに環境が分離されていないことが問題になる場合があります。 Pythonにおける virtualenv やRubyにおける Bundler を使えば、ジョブごとに利用するライブラリを分離することができます。しかし、C拡張ライブラリをインストールするためには、ジョブが実行されるノードに開発用のファイルが存在している必要があります。例えば、Pythonモジュールの lxml のインストールにはlibxml2やlibxsltの開発用ファイルが必要です。 *2 このようなファイルが必要になるたびにJenkinsのノードにインストールするのはスマートじゃないですし、実行に必要な環境はコードの形で明文化されているべきです。 ジョブでaptやyumを使ってインストールするのもセキュアじゃないですし、

    Dockerを使ってJenkinsのジョブごとにテスト実行環境を分離する - orangain flavor
  • Golang のコードカバレッジ測定とJenkins + Cobertura Plugin - fousの日記

    最近、Goで書いたプログラム+テストコードのカバレッジ測定ができないかなーということで、二つほど取り組んでました。 gocov-xml と、gocover-cobertura です。 ほぼ同じコトをするツールですが、入力元がgocov-xmlかgo tool coverかという違いがあります。 両方とも、結果をCovertura XML形式で吐き出すので、 Jenkins Cobertura Pluginにわせることができます。ソースコードアノテーション付き! 少し説明すると、まず前提として、Go言語でカバレッジ測定をする方法は二つあります。 一つは https://github.com/axw/gocov を使う方法で、`go test XXX`のかわりに` gocov test XXX`と書くことで、テスト実行+カバレッジ測定ができます。 もう一つは go tool cover ht

    Golang のコードカバレッジ測定とJenkins + Cobertura Plugin - fousの日記
  • テストダブル - Wikipedia

    テストダブル (Test Double) とは、ソフトウェアテストにおいて、テスト対象が依存しているコンポーネントを置き換える代用品のこと。ダブルは代役、影武者を意味する。 テストを実行するには、被試験システムに加えて、テスト対象が依存するコンポーネント (DOC; Depend-On Component) が必要になる。しかし、依存コンポーネントは、常に利用できるとは限らない。依存コンポーネントがテスト環境で利用できない理由には、次のようなものが挙げられる[1]。 入手できない。 テストで使いたい結果を返さない。 実行に時間がかかるなどの、望ましくない副作用がある。 こういった問題を回避するには、依存コンポーネントを、テスト用のコンポーネントと入れ替えるテクニックが利用できる。この代用のコンポーネントを、テストダブルと呼ぶ。 ジェラルド・メサローシュは、テストダブルのパターンとして、次の

  • CUnitによるテスト駆動開発

    はじめに CodeZineでの僕のデビュー記事『Cで実現する「ぷちオブジェクト指向」』、おかげさまでなかなか好評だったようです。まだまだCは現役だと実感しました。 前回に引き続きCのお話です。テストをよりどころに実装をすすめ、信頼できるコードを書くためのプラクティス「テスト駆動開発」(TDD:Test Driven Development)を、Visual C++ 2005 Express EditionとUnit Test Framework: CUnitで行います。 対象読者 そこそこのコードは書けるようになったけれど、どうも詰めが甘い/くだらないバグに出くわす/あっちを直すとこっちが壊れ、ぐだぐだになってしまう…そんな症状に悩まされている脱ビギナを目指すプログラマ。 テスト、してますか? 「プログラムは思ったとおりには動かない、作ったとおりに動く」 思ったとおりに作ってないと思ったと

    CUnitによるテスト駆動開発
    hiroyukim
    hiroyukim 2013/03/31
  • 1