テストに関するPET_HALのブックマーク (10)

  • ワイのテスト駆動開発〜偶数ハロー株式会社〜 - Qiita

    業務中ワイ ワイ「こないだ見た50分でわかるテスト駆動開発っていう動画おもろかったなぁ」 ワイ「ワイもテスト駆動開発やってみたいわ〜」 ワイ「まずは何か簡単な案件でTDDを導入してみたいわ〜」 そんなとき、クライアントから電話 ジリリリリ〜〜〜〜〜ン!1 ワイ「もしもし〜?」 ??「もしもし、株式会社ブラックの暗井 暗人(くらい・あんと)ですー」 ワイ「ああ、暗井はんでっか」 ワイ「いつもお世話になってます〜」 暗井「この前ご相談した件なんですけど、正式に発注お願いしますわー」 暗井「株式会社偶数ハローさんのWEBサイトの件ですわー」 ワイ「どんな案件でしたっけ?」 暗井「偶数ハローいう社名にちなんで、」 暗井「トップページにちょっとした仕掛けを設置しよう、いうやつですわ」 暗井「要は───」 ユーザーが奇数を入力したら、その数値をそのまま表示する ユーザーが偶数を入力したら、「ハロー」と

    ワイのテスト駆動開発〜偶数ハロー株式会社〜 - Qiita
  • なぜテストを書くの?(または書かないの?) 〜テストコードの7つの役割〜 / #tamarubykaigi01

    Tama Ruby会議01のキーノートとして発表したスライドです。 https://tama-rb.github.io/tamarubykaigi01/ 参加レポートはこちら。 https://blog.jnito.com/entry/2019/07/07/102734

    なぜテストを書くの?(または書かないの?) 〜テストコードの7つの役割〜 / #tamarubykaigi01
  • テスト駆動開発:実はそれは設計技術です

    テスト駆動開発(TDD)は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか?失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演

    テスト駆動開発:実はそれは設計技術です
  • 組織にテストを書く文化を根付かせる戦略と戦術(2019夏版) / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition

    デブサミ夏 【B-4】 2019/07/02 13:15 ~ 14:00 https://event.shoeisha.jp/devsumi/20190702/session/2077/

    組織にテストを書く文化を根付かせる戦略と戦術(2019夏版) / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
  • テスト初心者が知っておくべきブラックボックステストの種類と概要 - Qiita

    ブラックボックステストは、ソフトウェアが要件や仕様を満たしているかを確認するためのテストです。 「実際に関数が何をしているのか」といった具体的な実装に関する知識は必要としません。 要件定義書を元にしてテストケースを考えます。 ブラックボックステストは、単体テスト・統合テスト・システムテスト・受け入れテストといった全てのレベルのテストで行うことができます。 単体テスト:ソフトウェアの最小単位で行うテスト、関数やクラスなど 統合テスト:単体を組み合わせたときの挙動を確認するテスト、複数の関数を利用するプログラムなど システムテスト:ソフトウェア全体から構成されるテスト、機能性やユーザビリティ、セキュリティなど様々なタイプが存在する 受け入れテスト:顧客がソフトウェアを受け入れる条件となるテスト メリット ソフトウェアの入出力をすべて網羅する必要がないため、テストにかけるコストに対して最大限の効

    テスト初心者が知っておくべきブラックボックステストの種類と概要 - Qiita
  • テストの社内普及のための取り組みとして、Androidテストハンズオンを実施しました - DeNA Testing Blog

    こんにちは、SWETグループの田熊です。 先日、社内のAndroidアプリエンジニアを対象にユニットテストのハンズオンを行いました。 記事では、どのようなことを考えながらハンズオンを作成していったのかと、ハンズオンの内容を紹介しようと思います。 なぜハンズオンを開催したのか これまでのSWETは、メンバーがプロダクトに個別にジョインし、品質保証や生産性向上につながるような取り組みをしてきました。 一方、SWETが関わっていないプロダクトからも「テストがなくてつらい」などの声があがっていたため、自動テストのナレッジをスケールさせていくことも必要だと考えていました。 そこで、自動テストの普及の一貫としてテストハンズオンの実施を検討しました。 社内状況の把握 DeNAはサービスが多岐に渡るため、SWET内で各サービスにどの程度自動テストが普及しているかを把握できておらず、どのようなレベル感のハ

    テストの社内普及のための取り組みとして、Androidテストハンズオンを実施しました - DeNA Testing Blog
  • テストでダミーのユーザ名に迷ったときは「alice」や「bob」を使うといいよ - Qiita

    テストコードなどにダミーのユーザ名を書くことがある。ダミーの単語としてはfooやbar、日語圏だとhogeやfugaが業界的に有名だが、人物名にも業界的によく使われるものがある。アリスとボブだ。 アリスとボブは、暗号通信などの説明に登場人物名としてよく使われる。一般的に、アリスが送信者でボブが受信者、そしてキャロルがそれを傍受するといったシナリオが扱われる。 アリスとボブが暗号通信の説明で使われる例: 楽しく学ぼう公開鍵暗号方式 暗号通信とは関係なくても、単体テストのテストケースでユーザ名にaliceやbobを使うと、fooやhogeよりもテストコードより現実っぽく表現できるし、イニシャルがABCで覚えやすいし、業界でよく使われる架空の人物名なので、僕は好んで使っている。たとえば、PHPUnitでテストを書くときはこんな感じにする: final class EmailBuilderTes

    テストでダミーのユーザ名に迷ったときは「alice」や「bob」を使うといいよ - Qiita
  • テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING

    テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET(Software Engineer in Test)です。「SETタスクフォース」(以下「SETチーム」と表記)のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET(Software Engineer in Test)の伊藤 宏幸(Hiroyuki Ito)です。 2018年6月27日(水)に、電気通信大学の西 康晴さん(以下「にしさん」と表記)をお招きして、「

    テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 - Testing & Engineering - LINE ENGINEERING
  • test.comやaaa.comをテストデータに使うのはやめましょうという話 – 打つか投げるか

    2018/02/13追記:「サンプル用のドメインを使おう」の説明に “.example” と “.test” の使い分けについて追記しました。 Web システム開発時のテストデータを作成する時、また各種ドキュメントを書いている時など、サンプルの URL を使う場面は多いと思いますが、その時に適当なドメイン名を使うのはやめましょう、という話です。 知っている方には当たり前レベルの話ですが、意外と IT 企業のシステム開発現場等でも普通に見かけることがまだまだありますので・・・。 よく見かける例 例えば、こんなドメインの URL で開発中システムのテストデータを作っていたり、仕様書に説明が書かれていたりする場面をよく見かけませんか? test.com aaa.com abc.com sample.com dummy.com hoge.com でも、これらのドメインって存在していて、また実際に利

    test.comやaaa.comをテストデータに使うのはやめましょうという話 – 打つか投げるか
  • 市場バグを引き起こした優秀なデータたち - ボドゲを愛するテスト屋さん

    ※この記事は「ソフトウェアテストの小ネタ Advent Calendar 2017 - Qiita」用の記事です。 ソフトウェアテストの小ネタ 2日目担当のオムそばです。 実はちゃんとした(?)記事を書くのはこれが初めてなので、生暖かい目で見ていただければ。 そんなわけで早速表題の件、市場バグを引き起こした優秀なデータたちをご紹介します。 今回は、よくある「半角記号」、「空白やスペース」などは割愛させていただきます。 (2017/12/26追記)"市場バグ"という言葉に違和感や疑問を持たれた方は、こちらの記事をどうぞ。文言について整理してみました。 ■日時に関するデータ ・1969/12/31、2038/1/20:UNIX系のシステムに有効なデータ。UNIXのシステム時刻は1970/1/1 開始なので、それ以前のデータを打ち込むと予期せぬエラーが発生する可能性がある。また、同様に2038/

    市場バグを引き起こした優秀なデータたち - ボドゲを愛するテスト屋さん
  • 1