タグ

testingに関するnobeansのブックマーク (203)

  • 「GebとSpockではじめるシステムテスト自動化」

    2017/12/10 システムテスト自動化カンファレンス2017-2 「GebとSpockではじめるシステムテスト自動化」Read less

    「GebとSpockではじめるシステムテスト自動化」
  • テストフレームワーク mocha - hokaccha memo

    JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの

    テストフレームワーク mocha - hokaccha memo
  • 組織にテストを書く文化を根付かせる戦略と戦術

    1. The document discusses various social media and video sharing platforms and tools for integrating them, including YouTube, Twitter, Flickr, iTunes, and Facebook. 2. It mentions several services that allow embedding or sharing content between platforms, such as CDTube for YouTube, ZonTube for Amazon, and amz.ly for shortening Amazon URLs for Twitter. 3. Programming languages and APIs mentioned i

    組織にテストを書く文化を根付かせる戦略と戦術
    nobeans
    nobeans 2016/02/18
    熟成香がすごい
  • MacやLinuxでPICTを使う - 千里霧中

    組合せテストツールのPICTの解説で、表題についてよく聞かれるのでメモ。 PICTについては、専用のバイナリファイルで配布されていたこともあり、今までWindowsで使用されてきた。 ただ去年からGithubでオープンソース化され、gccやclangで自由にビルドできるようになった。それに伴い、MacLinuxでもWindowsと同じぐらい手軽に利用できるようになっている。 あえて言うまでもないかもしれないが、導入方法は以下の通り。最近のgccやclangが使え、makeできる環境であれば、OSは問わない。 「https://github.com/Microsoft/pict」にて、Download ZIPからファイルダウンロード、解凍 解答したディレクトリで「make」実行。同ディレクトリにバイナリpictができる。 使用例 このディレクトリに、例えば以下のようなファイルsample.

    MacやLinuxでPICTを使う - 千里霧中
  • 工数削減!GroovyでJUnitをシンプルに | Casley Deep Innovations株式会社 技術ブログ

    以下のように選択し、後は「OK」を選択してください。 完了後、Eclipseの再起動を求められますので、再起動してください。 ※既存プロジェクトに対してGroovyサポートを有効化するには、プロジェクトメニューを右クリックし、 [Configure]->[Convert to Groovy Project]を実行してください テストクラスの実装 テスト対象のクラスとして、以下のようなPersonクラスおよびそれを扱うUtilクラスをJavaで作成しました。 public enum Gender { MALE, FEMALE, } public class Person { private String country; private String name; private Gender gender; // getter,setter省略 } public class PersonUt

    nobeans
    nobeans 2015/07/29
    metaClassいじると後続のテストでハマるので、カテゴリクラスにしてuseで使うか、GroovyTestCaseを継承してregisterMetaClassを使うとかした方が良さげ http://mrhaki.blogspot.jp/2010/03/grails-goodness-using-metaclass-with.html
  • テスターは朝会から何を知るのか - CAT GETTING OUT OF A BAG

    わたしはちょっと意地悪らしい。 例えば、あるテストケースを思いついたとする(しかもかなりの高確率でうまく動かなそうなやつ)。それをね、モノが出来上がって自分の目でちゃんと動くこと(気持ち的にはちゃんと動かないこと)を見届けるまで、プログラマに話さない。*1 とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ!てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。 なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。 ということは、わた

    テスターは朝会から何を知るのか - CAT GETTING OUT OF A BAG
  • Goのテストの基本と開発フロー

    標準パッケージと小さいツールの組み合わせで十分テストできますよ的な話 @GolangTestNight(Gunosy.go#10)

    Goのテストの基本と開発フロー
  • クラウドワークス勉強会「レガシーコード改善の戦略と戦術」(後篇:戦術&懇親会) - CrowdWorks Engineer Blog

    こんにちは!開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇(戦略)に続き、後篇(戦術&懇親会)をお送りします。 「レガシーコード改善の戦略と戦術」 講師:和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP(eXtremeProgramming)を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い(完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念)」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド(テスト駆動開発者の証)を左手に着

    クラウドワークス勉強会「レガシーコード改善の戦略と戦術」(後篇:戦術&懇親会) - CrowdWorks Engineer Blog
    nobeans
    nobeans 2015/02/18
    “テストコードは フラット or DRY のどちらに書くべきなのか〜(略)〜歴史が答えを出しており、フラットに書くとコードの重複によりメンテナンスコストが高く〜(略)〜現在では「DRYに書くべき」という結論”
  • アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組

    はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。(言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを

    アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
  • テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組

    はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか?」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま

    テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
  • テスト全体の良い書き方について。 #swtest_jp - うさぎ組

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

    テスト全体の良い書き方について。 #swtest_jp - うさぎ組
  • 週刊ソフトウェアテスト 2014-創刊号 #swtest_jp - うさぎ組

    前書き ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。創刊号なので、若干時期が広めになってるのと、選択基準がまだハッキリしていない部分もございます。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです!(なにかの紹介でも、議論でも、質問でも! Summary CIaaS(CI as a Service)のCircle CIに無料のプランが追加されました。個人的には、CloudBeesの無料枠からの移行組をとろうとしているのかなぁ?と感じました。 HTTPSの無償利用が実現に向けて動き出しました。実現すれば、HTTPSのテストをしづらかったたくさんの開発チームが救われそうです

    週刊ソフトウェアテスト 2014-創刊号 #swtest_jp - うさぎ組
  • 脱・独自改造! GebでWebDriverをもっとシンプルに

    第2回日Seleniumユーザーコミュニティ勉強会(http://seleniumjp.connpass.com/event/9222/)の発表資料です。 サイボウズのエンジニアブログで補足記事を書いています。 http://developer.cybozu.co.jp/tech/?p=7934

    脱・独自改造! GebでWebDriverをもっとシンプルに
  • TTDD - Tautological Test Driven Development (Anti Pattern)

    One of the advantages of being a consultant is getting to see different environments and being able to visualise and identify patterns and anti-patterns. "An anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice" http://en.wikipedia.org/wiki/Anti-pattern As a first step, let’s describe TTDD – Tautological Test Driven Development as an anti-patt

    nobeans
    nobeans 2014/05/14
    こういうテスト書いたことあるわー/"トートロジカル"はなるほどなぁと思うけど"TDD"関係ない気が。テストの書き方アンチパタンなだけでは/最後のモック→スタブの書換はsetupが多少隠蔽された、程度の嬉しさ?
  • 「TDD is dead. Long live testing」 まとめ - quattro_4 scribble

    RailsConf 2014 Is TDD dead? Is TDD dead? [Part II] Is TDD dead? [Part III] Is TDD dead? [Part IV] Is TDD dead? [Part V & VI] (40分くらいの Kent frozen がうける) TDD is dead. Long live testing. (DHH) 翻訳 2014-04-24 - やっとむでぽん 自動化したリグレッションテスティングが存在しないという残念な業界の現状 TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている 間接的で過剰に複雑な構造を生みがちだ。「遅い」ものをすべて避けようとする 伝統的な意味でのユニットテストはほとんどしない。すべての依存関係をモックにし、何千というテストが数秒で終わるようなユニットテスト 我々は完全なシステムテス

    「TDD is dead. Long live testing」 まとめ - quattro_4 scribble
    nobeans
    nobeans 2014/05/12
    これはよいまとめ。今回の一件は、想像してた以上に大御所達がmockを局所的にしか使っていない(またはまったく使わない)ことがわかったのが収穫。t-wadaもかなり前からそう言ってた。
  • Clean Coder Blog

    A mock object is a very powerful tool, providing two major benefits: isolation and introspection. But like all power tools, mocks come with a cost. So where and when should you use them? What is the cost/benefit trade off? Let’s look at the extremes. ##No Mocks. Consider the test suite for a large web application. Let’s assume that test suite uses no mocks at all. What problems will it face? The e

    nobeans
    nobeans 2014/05/10
    ボブおじさんによるMockとの付き合い方指南/"全く使わない〜使いすぎの中庸が肝要" "DBやNWのような構造上の境界に使う" "モックライブラリに依存しない。場合によって自前で実装" "指針であってルールではない"
  • Martin Fowler's Bliki in Japanese - ユニットテスト

    http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった (この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ)。 ユニットテスティングは

    Martin Fowler's Bliki in Japanese - ユニットテスト
  • TDD/BDDの思想とテスティングフレームワークの関係を整理しよう

    TDD/BDDの思想とテスティングフレームワークの関係を整理しよう:いまさら聞けないTDD/BDD超入門(2)(1/3 ページ) TDD/BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、TestDoxを紹介する。 前回の「テスト駆動開発/振る舞い駆動開発を始めるための基礎知識」でも紹介があったように、さまざまなテスティングフレームワークがあります。例えばTDD自体は、Kent Beck(ケント・ベック)氏が著書『テスト駆動開発入門』(ピアソンエデュケーション刊)の中で述べているように、「分析技法および設計技法であり、実際には開発全てのアクティビティを構造化するための技法」です。 TDD(テスト駆動開発)/BDD(振る舞い駆動開発)を実践することと、特定テスティングフレームワークを採用したり開発したりすることを分けて考えておかな

    TDD/BDDの思想とテスティングフレームワークの関係を整理しよう
  • SikuliスクリプトでのUI操作自動化を試してみる

    SikuliスクリプトはOpenCVを使った画像認識を利用して、GUI操作の自動化を行うスクリプトです。 指定した画像に一致した領域にカーソルを動かしてクリックさせたり、キーボードでの入力をさせたりすることができます。 そこで、今回はSikuliがUIテストに利用できるのかどうかを調べるために、iOSシミュレータに対してSikuliスクリプトを試しに使ってみました。 なお、MITUIデザイングループが始めたオープンソースの研究プロジェクトであり(ソースはGitHubにあります)、現在はコロラド大学ボルダー校のSikuli Labがメンテナンスしているようです。 ダウンロードから起動まで Sikuliのサイトのダウンロードページからdmgファイルをダウンロードします。これをマウントして実行するだけです。 なお、Lion以降を利用している場合には、Gatekeeperの設定によって実行できな

    SikuliスクリプトでのUI操作自動化を試してみる
  • 不安をテストにするということ #tddadventjp - bluebird

    このエントリーは、TDD Advent Calendar 2013の参加エントリーです。 前日のエントリーは、moonmileさんによるTDD - ノーマルにMSTestを使おう - Qiita [キータ]でした。 テスト駆動開発(TDD)でよく語られるキーワードに「不安をテストにする」という言葉があります。 これは、どういうことでしょうか。 ケントベックの「テスト駆動開発入門」は、このように述べています。 テスト駆動開発は、プログラム中の不安を管理する方法である。ここで言う不安とは悪い意味ではない。...(略)...道理にかなった不安、すなわち「これは困難な問題だから最初から最後までは分からない」という感覚である。 (「テスト駆動開発入門」まえがきから) 即ち、プログラマがキーボードを打つことを阻害する、「プロダクションコードをどのように書けばいいのかわからない」という不安を、失敗するテ

    不安をテストにするということ #tddadventjp - bluebird