タグ

TutorialとTestに関するko-ya-maのブックマーク (31)

  • 複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO

    ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか?という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は当に有効なのか?組み合わせテスト技法と上手に付き合う方法 | DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか?条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I

    複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO
    ko-ya-ma
    ko-ya-ma 2019/10/18
    直交表全部を網羅するテストを書かなくても2要素のテストで7割のバグは潰せるよっていう例のアレ。PICTを使用している
  • 外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck

    Oct 31, 2018 at AWS Dev Day Tokyo 2018 #AWSDevDay #AWSTDD

    外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
  • VSCodeでTypeScript/Node.jsの開発環境を作る(UT・カバレッジ・ログ出力・リリース手順含む) - Qiita

    Visual Studio CodeでTypeScriptの開発環境を作る手順を調べてみました。 Node.jsで動く簡単なCLIツールを作る前提で進めていきますが、他の開発にも応用できるかと思います。 なお、Visual Studio CodeとNode.jsはインストール済みの前提です。 Windows 10環境で以下のバージョンで確認しています。 C:\>node -v v8.10.0 C:\>npm -v 3.10.6 C:\>code -v 1.21.1 79b44aa704ce542d8ca4a3cc44cfca566e7720f1 x64 mkdir ts-sample cd ts-sample npm init -y mkdir .vscode src test config npm i -SEB config log4js npm i -DE typescript ts-

    VSCodeでTypeScript/Node.jsの開発環境を作る(UT・カバレッジ・ログ出力・リリース手順含む) - Qiita
  • 依存性注入(DI)の解説とやり方 - Qiita

    依存性注入 (Dependency Injection) は、クラスを単体テスト可能にするために使われるテクニックです。 これが意識されていないが故に単体テストが全くできないコードをよく見かけます。 単体テストの際には必ず必要になる知識なので、解説しておきます。 以下のサンプルでは PHPUnit を利用しています。 悪い例: 単体テストができないケース 以下のような Foo クラスの play() メソッドは、単体テストケースが書けません。 class Foo { public function play() { $bar = new Bar(); if ($bar->getSomething() === 1) { return true; } return false; } } play() 内で外部クラス Bar をインスタンス化しています。つまり Foo::play() メソッドは

    依存性注入(DI)の解説とやり方 - Qiita
    ko-ya-ma
    ko-ya-ma 2018/03/08
    わかりやすい
  • 関数型言語Elmでテスト駆動開発(第1~4章) - Qiita

    遂に新訳「テスト駆動開発」が発売されましたね!今回の記事では第一部のJavaで書かれているコードを関数型言語Elmでテスト駆動開発(TDD)に挑戦してみたいと思います!その狙いは、以下の通りです。 写経ではなく別言語で書き換えることで、TDDの習得を目指す Elm自体の勉強 オブジェクト指向プログラミングとの違いを明らかにする 関数型言語がTDDに適しているかを検証する 関数型言語やElm自体の布教 目的のほとんどが検証・学習や布教目的ですが、今回の記事の内容を書いている時点で既に関数型のパワーを大きく実感しております。初回の内容にして1~4章なのは、その力が強大がゆえです。どれほどElm-TDDを続けるかわかりませんが、なるべく第一部の内容完結を目指したいと思います。 方針と注意事項 この記事の方針ですが文の内容やコードは、著作権を考慮して極力載せすに、ElmによるコードとテストのTO

    関数型言語Elmでテスト駆動開発(第1~4章) - Qiita
  • Shows

    AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Find out how you can use GitHub Copilot, an add-on that is powered by AI, to get helpful suggestions when writing code or documentation. This

    Shows
  • テスト自動化研究会 - 4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス

    オープンソースのブラウザテストツール「Selenium WebDriver」の使い方と、テストスクリプトを効率よくメンテナンスする方法について、実際にプログラムを書きながら学べるチュートリアル形式教材です。 前半は、Selenium入門ドリルです。基礎から丁寧に解説されているので、Seleniumは初めての方でもテストが書けるようになります。 後半では、テストのメンテナンス効率をあげるための技法「ページオブジェクトデザインパターン」の習得を目指します。こちらも基礎から解説していくので、Seleniumが初めての方でも大丈夫です。 プログラミング言語Javaでテストスクリプトを作成するので、Javaで基的なプログラムが書ける必要があります。 自習教材として利用する場合 前提知識・事前準備手順ドキュメントの手順に従い、必要な事前準備とインストールを完了させます。作成したEclipseプロジェ

    テスト自動化研究会 - 4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス
  • ゼロから始めるJavaScript生活 - Qiita

    (訳者注: これは、JavaScript Stack from Scratchを翻訳し、まとめて読めるように1ファイルにしたものです。元の翻訳と各種ファイルについては、日語訳forkリポジトリを参照してください。また、原文が活発に更新されているため、訳文も追従して更新されます。ご了承ください。) モダンJavaScriptスタックチュートリアル、ゼロから始めるJavaScript生活へようこそ。 ⚠️️ このチュートリアルのメジャーアップデート版を3月初旬に公開する予定です。ご期待下さい! より詳しく(英語). これはJavaScriptスタックを使い始めるための最短最速のガイドです。このガイドは一般的なプログラミングの知識とJavaScriptの基礎を前提としています。これら全てのツールを一緒につなぎ合わせることにフォーカスしており、各ツールについて可能な限りシンプルな例を提供します。

    ゼロから始めるJavaScript生活 - Qiita
    ko-ya-ma
    ko-ya-ma 2016/11/03
    濃密。ステキ。でも、モダンなプログラミングの勘所を掴んでいる人じゃないと、必要性や便利さがわからないかも。Riot.jsをちゃんと使えば、babel,gulpあたりを覚えずとも恩恵を受けられるし、reduxも行けるぞと布教
  • 第23回 mysqlslapを使って負荷テストをしてみよう | gihyo.jp

    ここでは以上のようなオプションを利用しています。実行した結果は次のようになります。 Benchmark Average number of seconds to run all queries: 0.001 seconds Minimum number of seconds to run all queries: 0.001 seconds Maximum number of seconds to run all queries: 0.002 seconds Number of clients running queries: 1 Average number of queries per client: 0 平均実行時間や最小・最大の実行時間、実行したクライアント、クライアントが発行したSQLの数などが一目でわかるようになっています。 注意点としては、mysqlslapというデータベース

    第23回 mysqlslapを使って負荷テストをしてみよう | gihyo.jp
  • ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD

    最小限の設定のTDD手法を使い、「何をテストすべきか?」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出

    ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
  • Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO

    負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観

    Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO
  • 負荷テストツールGatlingを触ってみた - 絶品ゆどうふのタレ

    負荷ツールとしてGatlingのことを少し前から耳にする機会が増えたので、利用してみることにした。 色々既出だとは思うが、公式のQuickstartに従って試してみたのでメモ。 GUIが必要だったので、今回は手元のMacで実行。 Gatlingとは Java/Scala製の負荷テストツール。 JMaterと似た感じのツールではあるが、 ハイパフォーマンス 見やすいレポートHTML developerフレンドリーなシナリオファイル というのをウリとして謳っている。 たぶん、3項目とも対JMater(重い・レポート見づらい・XMLのシナリオつらい)を意識したメリットだろうなー。 なお、シナリオファイルは。。。 Gatling simulation scripts are written in Scala, but don’t panic! わろた。 というわけで、触ってみる Install J

    負荷テストツールGatlingを触ってみた - 絶品ゆどうふのタレ
  • Webアプリケーション負荷試験実践入門

    2015年2月24日 ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less

    Webアプリケーション負荷試験実践入門
    ko-ya-ma
    ko-ya-ma 2015/02/26
    親切丁寧な解説
  • PAGE NOT FOUND!

    Sorry, but the current page is not working right now. Thank you!

  • PHP版レガシーコード改善に役立つ新パターン #wewlc_jp

    9/27に行われたレガシーコード改善勉強会で発表された資料です。 http://passmarket.yahoo.co.jp/event/show/detail/01pitgwzj67m.htmlRead less

    PHP版レガシーコード改善に役立つ新パターン #wewlc_jp
    ko-ya-ma
    ko-ya-ma 2014/10/21
    レガシーコードから逃げずに戦ってるなあ。まずはチームの意識改革からか
  • iOSアプリデザインリニューアルの舞台裏の舞台裏 - クックパッド開発者ブログ

    技術部の松尾(@Kazu_cocoa)です。 iOSアプリデザインリニューアルの舞台裏でも書かれていた、" 修正期間中は毎日夜間にアプリケーションの全画面のスクリーンショットを記録するスクリプトを実行し、画面崩れが起きてないか、新デザイン未反映の画面はないか、進捗状況の確認に利用していました。"の舞台裏を少し書いてみようと思います。 はじめに モバイルアプリケーションのテスト環境はまだまだ成長中で、様々なツールが飛び交っていることかと思います。ここでは、E2Eテストに対しての話題に絞り、使っているツール、シナリオの書き方、クックパッドでは、という話しをします。この記事におけるE2Eテストは、UIからの操作によりユーザの操作を模倣して実施するテスト、という意味合いです。 ツール E2Eテストを自動化する為のツールの選定には以下を気にしていました。 OSの更新に追従できそうなもの 特別なテスト

    iOSアプリデザインリニューアルの舞台裏の舞台裏 - クックパッド開発者ブログ
  • fuelPHPでPHPUnitを使ったユニット・コントローラーテストをするには - Qiita

    fuelPHPでユニット・コントローラーテストしようと思ったら意外に情報がなかったのでまとめました。 前準備 PHPUnitのインストール プロジェクトのcomposer.jsonのrequireにphpunitを追加します。 "require": { "php": ">=5.3.3", "composer/installers": "~1.0", "fuel/docs": "1.7.2", "fuel/core": "1.7.2", "fuel/auth": "1.7.2", "fuel/email": "1.7.2", "fuel/oil": "1.7.2", "fuel/orm": "1.7.2", "fuel/parser": "1.7.2", "fuelphp/upload": "2.0.1", "monolog/monolog": "1.5.*", "michelf/php-m

    fuelPHPでPHPUnitを使ったユニット・コントローラーテストをするには - Qiita
  • Selenium2でつくるテストケースの構成について

    2. なにを発表するの?  最近、Selenium2 + Ruby + RSpec でブラウザ テストの自動化に取り組んでます  「ブラウザテスト」?  ここでは「テスターがブラウザを操作して眼で結果 を確認する行為」という意味で使います  具体的にどんなことをやってるのかを紹介し ます。 (主にテストケースの構成について話します) 4. Slenium2って何?  OSSのブラウザテストツール  プログラム言語でテストスクリプトを書いて使う  何ができるの?  手動テストの代替  手動テストで行うのと同様に、実際にWebブラウザを起 動して操作できる  ボタン押したり、文字列を入力したり取得したりetc  特徴・メリット  ブラウザテストツールのデファクトスタンダード  情報&使用経験者の数が多い  開発が活発  幅広いOS/ブラウザ/言語に対応

    Selenium2でつくるテストケースの構成について
  • TDD/BDDの思想とテスティングフレームワークの関係を整理しよう

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

    TDD/BDDの思想とテスティングフレームワークの関係を整理しよう
  • Jenkinsでビルド・パイプラインを作る

    Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 #12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの1つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。(

    Jenkinsでビルド・パイプラインを作る