タグ

Testに関するdecoy2004のブックマーク (127)

  • JUnit5 使い方メモ - Qiita

    package sample.junit5; import org.junit.jupiter.api.Assertions; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.DisplayName; class JUnit5Test { @Test void fail() { Assertions.assertEquals(10, 8); } static class StaticClass { @Test void fail() { Assertions.assertEquals(10, 8); } } static class StaticTest { @Test void fail() { Assertions.assertEquals(10, 8); } } class InnerTest { @Te

    JUnit5 使い方メモ - Qiita
  • モダンなテスト管理プロセスのためにテスト管理ツール3つを比較検討したはなし | メルカリエンジニアリング

    こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。 テスト自動化をすすめるにあたり、効率のよいテストを作るために、既存のテストケースについて調べる機会がありました。その過程で現状のQAプロセスも確認したのですが、以下のようなテストケース管理の課題があることがわかりました。 それぞれのテストエンジニアが、それぞれの方法で、それぞれのテストケースを管理しているため、ナレッジが横につながりにくい。 共有されているリグレッションテスト項目の更新が追いついておらず、情報が古くて使いにくい。 人数が増えてきて、ふりかえりや改善がやりにくい。 1については、現在、職能横断的なチーム構成になっているため、プロジェクトやプロダクトに集中できる環境である反面、それぞれのチームにいるQAエンジニアどうしのつながりが薄れてしまうことが原因に感じ

    モダンなテスト管理プロセスのためにテスト管理ツール3つを比較検討したはなし | メルカリエンジニアリング
  • Seleniumアレルギーのための処方箋 - Qiita

    何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先

    Seleniumアレルギーのための処方箋 - Qiita
  • ブラウザテストツール総まとめ・2016年夏版 - Qiita

    GitHubのスターは2016年7月30日調べ。ただし、登場年によるバイアスが激しいので、この件に関してはあまり参考にならないですね...。 E2Eテストツール Nightwatch 総合的なE2Eテストツール。WebDriver実装(独自)と、アサーションライブラリが一体となっているのが、使いやすいような使いにくいような。 http://nightwatchjs.org/ https://github.com/nightwatchjs/nightwatch 書き方はこんな感じ。 module.exports = { 'Demo test Google' : function (client) { client .url('http://www.google.com') .waitForElementVisible('body', 1000) .assert.title('Google')

    ブラウザテストツール総まとめ・2016年夏版 - Qiita
  • TravisCIで実ブラウザ環境のテストを行う方法 | チャットワーククリエーターズブログ

    骨折しました。@kyo_agoです。 今日はTravisCI上で実ブラウザ環境のテストを行う方法を紹介したいと思います。 弊社ではこれまで実ブラウザ環境のテストではTravisCIからProtractorを使ってSauceLabsへ接続してテストを行っていました。 しかし、これには以下のような問題があったため、ProtractorとSauceLabsを使用しない構成へ移行しました。 テストが高頻度で失敗するテストに影響しない部分の修正ですらテストが失敗し、コードの修正よりテストを通すほうが難しい状況になっていました。 (これは社内では「e2eガチャ」と呼ばれ、レビュー依頼のコメントには「e2eガチャ 1/5」と成功率が書かれていました。ちなみに「1/5」はわりといい確率です。悪い時は「1/12」くらいになります) 遅いSauceLabsへの接続時間、WebDriver経由のテスト実行などは

    TravisCIで実ブラウザ環境のテストを行う方法 | チャットワーククリエーターズブログ
  • Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ

    こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。 初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。 見直しのきっかけ トレタは飲店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。 製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。 入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいち

    Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ
    decoy2004
    decoy2004 2016/07/07
    デシジョンテーブルや原因結果グラフはどうやって書いているんだろう。 Markdown は使いづらい。 #test
  • テストエンジニアの面接の際にするとよい20の質問

    みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます

    テストエンジニアの面接の際にするとよい20の質問
  • Java テストツールのトレンド 2014/1~2016/5 - Qiita

    Java テストツールのトレンド 2014/1~2016/5版 1. エコシステムに乗っかるべし 継続的インテグレーション(CI:continuous integration)は、もはや必須のプラクティスとなりました。CIを実施するにあたり、できるだけ世の中でよく使われているツールやフレームワークを使うことが、エコシステムにスムーズに乗っかっていく鍵になります。マイナーなツールやフレームワークを採用してしまった場合の問題点を挙げてみます。 採用したツールの開発が停滞していてバージョンアップによる恩恵が受けられない。 他のツールのバージョンアップに採用したツールが追従できず、他のツールのバージョンアップの恩恵が受けられない。 足りない機能があり社内で色々作りこんだものの、社内のスピードよりも、世の中のスピードのほうが速く、システムの改修が世の中に追従できななくなってしまう。 CIシステムの維

    Java テストツールのトレンド 2014/1~2016/5 - Qiita
  • QuickCheck でテストデータを半自動生成する - Qiita

    概要 Property Based Test を実装するためのライブラリ「QuickCheck」の Java 移植版を試してみました。 Property Based Test とは 以前の渋谷Javaで @gakuzzzz さんがおっしゃっていたのによると下記のようなものだそうです。 テストデータを半自動生成……テストデータを管理する必要がない すべての値について性質を満たすことをテスト 機能変化や仕様変化に強い Java にも QuickCheck ファミリーのライブラリがある テストデータを作るのが面倒な場合や、あらゆる値を網羅的にテストしたいケースで役立つようです。なお、境界値テストのような固定の値を必要とするものは、通常通りの JUnit Test を書けばよいとのことでした。 Java の QuickCheck 実装 QuickCheck は Haskell のライブラリです。今

    QuickCheck でテストデータを半自動生成する - Qiita
  • Selenium IDEで記録したテストスクリプトをSIToolkitで実行する - システム開発現場の道具箱

    Selenium IDE(Firefox Plugin)で記録したテストスクリプトをSIT-WTで実行する方法を紹介します。 これにより、エビデンスの取得やテストケースの複製が簡単にできるようになります。 セットアップ SIT-WTのクイックスタートにある実行環境の準備を行ってください。 次に、以下ソフトウェアの最新バージョンをダウンロードしてインストールします。 Selenium IDE LibreOffice ※拡張子が「xlsx」のエクセルを編集できるソフトウェアがあれば、LibreOfficeはインストール不要です。 上記ソフトウェアの準備ができたらmyprojectというディレクトリを作成し、その中に下記pom.xmlをダウンロードして配置してください。 pom.xml myproject - pom.xml Selenium IDEでテストスクリプトを記録する Selenium

    Selenium IDEで記録したテストスクリプトをSIToolkitで実行する - システム開発現場の道具箱
  • Selenide~Javaで超簡単・簡潔にUIテストを書く~ - Qiita

    はじめに Selenideを触ってみたら簡単なUIテストがサクッと書けて感動したので、使い方をまとめました。 Selenideとは SelenideはUIテストのためのSeleniumラッパーです。 Selenide: concise UI tests in Java http://selenide.org/ Java界隈でUIテストといえばSelenium(WebDriver)が有名で、大変優れたツールです。ですが、SeleniumはUIテストのためのツールではなく、ブラウザ操作のためのツールです1。 一方、Selenideは初めからUIテストのために設計されていて、UIテストを「スラスラ」書いて実行できます。ブラウザの閉じ方とか、タイムアウトとか、StaleElement Exceptionsの扱い方などを考える必要はなく、ユーザはテストに集中できるのが売りです。 Three simp

    Selenide~Javaで超簡単・簡潔にUIテストを書く~ - Qiita
  • AssertJ / Fluent assertions for java

    AssertJ Core site has moved to https://assertj.github.io/doc/ This site is still maintained for AssertJ modules (until their documentation is migrated) Rich and easy to use AssertJ provides a rich set of assertions, truly helpful error messages, improves test code readability and is designed to be super easy to use within your favorite IDE. Get started right away with the one minute starting guide

  • テストの数を減らそう!プリキュアで学ぶPICT - Qiita

    ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか?最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても

    テストの数を減らそう!プリキュアで学ぶPICT - Qiita
  • JaSST'16 Tokyo まとめ #jasst #jasst16

    テス太郎 @Tesutaro_JaSST 今日はJaSST Tokyo一日目。基調講演のテーマは今、トレンドのIoT。みんなビックなウェーブに乗りにいこう pic.twitter.com/1Yw6JByOgq テス太郎 @Tesutaro_JaSST セッション紹介の前にセッションIDの説明だよ。 セッションはABCDEFと6つ並行で開催されます。そしてチュートリアルはG。 どのセッションがどの会場になるかは参加希望人数によって決まるため、当日掲示します。会場がわからなかったら最寄りの実行委員をつかまえてね。 テス太郎 @Tesutaro_JaSST そしてセッション番号はアルファベットと数字で示しています。 数字は時間帯を表しています。 2:1日目午後 13:10から90分 3:1日目午後 15:10から60分(チュートリアルは170分) 4:1日目午後 16:50から90分

    JaSST'16 Tokyo まとめ #jasst #jasst16
  • テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita

    この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要!という風潮であるのに、何故テストが重要であると実感できないのでしょう

    テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
  • JUnit.org

    The 5th major version of the programmer-friendly testing framework for Java and the JVM User Guide Javadoc Code & Issues Q & A Support JUnit JUnit team’s statement on the war in Ukraine As human beings, we stand with Ukraine and condemn the Russian government’s war against the Ukrainian people, including our own colleagues and their families. Donate to UN’s Ukraine Humanitarian Fund About JUnit 5

  • power-assert/README.md at master · power-assert-js/power-assert

    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

    power-assert/README.md at master · power-assert-js/power-assert
  • TestLinkで手動テストと自動テストを統合する : JUnit編 - Qiita

    徐々にテスト自動化していく場合のニーズ コンポーネントテストや統合テストなど開発者主体の自動テストの場合最初から自動テストのみを管理して、特に手動テストと管理をまとめたいというニーズはありません。 しかし、システムテストレベルの場合、全自動化がされていることは少なく、また現実的ではないので、現状手動のテストを徐々に自動化していくというのが良くあるパターンではないでしょうか? そのような徐々に自動テスト化していく中では手動テストと自動テストを同時にリグレッションテストやスモークテストとして行ったりするので、両方をまとめて管理したい、まとめて状況を見たいというお話をマネージャーさんからリクエストされることが度々あります。 私にそんな話が来るぐらいと言うことは世の中でもそういうニーズがあるに違いない、そもそもHPのQuality CenterやIBMのRational Quality Manag

    TestLinkで手動テストと自動テストを統合する : JUnit編 - Qiita
  • Gatling でぶっ放せ! - Qiita

    What's this? Java/Scala 製の負荷テストツール http://gatling.io Install Java Install/Setup Gatling 負荷テスト実施 Install/Setup nginx 負荷テスト結果をブラウザで確認 Install java # yum install java ================================================================================================================================== Package Arch Version Repository Size ====================================================================

    Gatling でぶっ放せ! - Qiita
  • サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ

    技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの体アプリケーションや、新規にあるいは体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに

    サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ