タグ

テストに関するuneasyのブックマーク (29)

  • 技術的負債とならないテストコードを書くために考えること - Qiita

    概要 プロダクト開発を行う上で、テストコードは重要な要素であるかと思います。 ユニットテストコードを書くことで、クラス単位の動作保証を行うことが出来ます。また、E2Eテストやインテグレーションテストを書くことで、DBアクセスや外部連携を含めた、プロダクトにおける一気通貫の動作を確認することが可能になります。 作成したテストコードは、CICDと組み合わせて、自動テストとして定期的に実行させます。これにより、既存のソースコードを変更した際の品質を (ある一定レベルにおいてですが) 担保することが出来るようになります。結果として、開発メンバーは積極的なリファクタリングを行えるようになり、健全な開発のライフサイクルが回る・・・という流れになります。 テストコードも、プロダクションコードと同様に、継続的に保守・開発していく必要があり、一定のお作法に則って開発していく必要があります。無秩序で設計が不十

    技術的負債とならないテストコードを書くために考えること - Qiita
  • あなたが自動テストを行う目的は何ですか? - Qiita

    この記事はソフトウェアテスト Advent Calendar 2019の24日目です。 前日の記事はまつや大先生のクリスマススペシャル 「AIが使われたオススメ機能」のテストのやり方でした。そういえば書籍化決定したそうですね!!!おめでとうございます!!! TL;DR 緑色の会社のテスト自動化/SETチームのマネージャー( https://twitter.com/ozonohiroaki ) スクラッチから自動テストを始めたときの失敗談 目的って大事 はじめに もともと今回のアドカレではゴリゴリの技術記事を書かせていただく予定にしていたのですが、あるツイートの反応を受けてちょっと内容を泥臭いものに変更させていただくことにしました。 そのツイートというのがこちら 福岡でテスト自動化ミートアップしようと思ってるんですが需要ありますかね? 気付けば丸3年で相当な数の失敗経験させていただいてること

    あなたが自動テストを行う目的は何ですか? - Qiita
  • 20年物のC言語で作られたシステムのテスト工程を改善しようとした話 - Qiita

    はじめに ちょっと前に20年物のC言語で作られたシステムのテストを色々改善しようとしてみたので、この時に得たちょっとした知見を書いていこうと思います。 ※注意 記事を書くために自分のパソコンで当時を思い出しながら環境を作っているので、実際、実務でやった環境やバージョンとは違います。 また、この記事にはいくつかコードがでてきますが、すべて記事を書くために考えた疑似的な例にすぎません。 単体テスト用のテストコードの作成 20年も動いているシステムだと、もはや誰にも意味はわからんが、既存の挙動を変えてはいけない箇所がいくつもあります。 そういう箇所に手を入れざるを得ないときに、有効な方法として以下のような方法があります。 まず、既存のコードに対するテストコードを記載します。そして全て合格することを確認してから、少しづつ機能を拡張していきます。 これにより、新規機能追加が既存の機能を壊していないこ

    20年物のC言語で作られたシステムのテスト工程を改善しようとした話 - Qiita
  • 我が名は神龍……どんなテストもひとつだけ自動化してやろう - Qiita

    『我が名は神龍……どんなテストもひとつだけ自動化してやろう』 じゃ、じゃあ!このブラウザテストを自動化してください! Chromeで https://kids.yahoo.co.jp/ にアクセスして 検索ワードに ねこ と入力して さがすをクリックして 検索結果にネコ - Wikipedia が含まれていることを確認して 検索結果に 買い方 を追加して さがすをクリックして 探しているのは「の飼い方」?と表示されることを確認して クリックするとの飼い方で再検索されて 検索ボックスを不倫で上書きして さがすをクリックして このページは表示できませんと出ていることを確認 『よかろう……たやすい願いだ』 まずはライブラリのインストールと初期設定をしてやろう…… # [ライブラリのインストール] # CodeceptJSとPuppeteerをインストールします。nodeとnpmが必要ですので

    我が名は神龍……どんなテストもひとつだけ自動化してやろう - Qiita
  • 結合テストと呼ぶのをやめた話 - asterisc

    はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類(small / medium / large)に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを

    結合テストと呼ぶのをやめた話 - asterisc
  • 構成ファイルの通りにインフラは立ち上がったのか? インフラ自動テストツール「Terratest」がオープンソースで公開

    構成ファイルの通りにインフラは立ち上がったのか? インフラ自動テストツール「Terratest」がオープンソースで公開 クラウドの利用において、インフラの構成をコードで記述することは一般的になってきました。インスタンスのサイズや台数を指定し、仮想マシンのイメージを指定し、ネットワーク構成を指定する、といった内容を記述したファイルを用意し、ChefやAnsible、Terraform、あるいはAWS CloudFormationといったインフラ構成ツールで実行することで、つねに同じ構成のインフラを立ち上げることができます。 インフラの構成を変更する際にもGitHubのようなバージョン管理システムでインフラの構成コードを管理できるため、いつ誰がどのようにインフラを変更したのか、履歴の管理が可能になると同時に、問題が発生した場合には以前の状態に戻すこともできます。 オープンソースで公開された「T

    構成ファイルの通りにインフラは立ち上がったのか? インフラ自動テストツール「Terratest」がオープンソースで公開
  • Golangでtestingことはじめ(1)〜testingパッケージを使ったユニットテスト〜 - DeNA Testing Blog

    こんにちは。 Golangが一般的に使われるようになってきてもう久しいですね。 最近作られたSWET製のツールでも、Golangを採用したものがあります。 そこで、Golangの標準テストパッケージtestingやその他についてまとめたいと思います。 今回から3回にわたり、 testingパッケージを使ったユニットテスト(testing) テストにおける共通処理(testing) アプリケーションのテスト(gomock, httptest) を紹介します。 この記事を読んで一通りGolangでテストがかけるようになると嬉しいです。 この文章中に登場するサンプルは GitHub にありますので、実際に動作させることが可能です。 $ go get github.com/duck8823/sample-go-testing $ cd $GOPATH/src/github.com/duck8823

    Golangでtestingことはじめ(1)〜testingパッケージを使ったユニットテスト〜 - DeNA Testing Blog
  • Goでテストを書く(テストの実装パターン集) - Qiita

    Goでテストを書くお話です。 基的なところから、応用的なテストの書き方(パターン?)をまとめておくことにしました。 ポイントを先に列挙します: テストのエラーメッセージは丁寧に書こう テーブルテストを活用してパターンを整理しながら網羅しよう t.Runをつかって大きなテストを分割しよう t.Helperをつかってテストエラーの箇所をわかりやすくしよう テスト用のデータは testdata ディレクトリに置こう Setup/Teardownをうまく書いてテストの見通しをよくしよう 等 では、見ていきましょう。

    Goでテストを書く(テストの実装パターン集) - Qiita
  • メルカリのQAエンジニアがテスト自動化に挑んだ話 | メルカリエンジニアリング

    はじめまして!QAエンジニアのkinoshです。 みなさんは「自動化」と聞いて、どんな期待をしますか? 生産性アップ?高い品質?スピード?いろいろな期待があると思います。 現在メルカリQAでは、繰り返し行われる部分や、機械のほうが得意な部分をどんどん自動化して、節約できた時間を、人間しか見つけられない作業(不具合を探索したり、仕様からリスクを洗い出したり)に使っていこうと日々奮闘中です。 この記事では、最近私が主導で進めたテスト自動化について、自身が学んだ知見などを共有いたします。 進んでいた自動化 メルカリにはQA-SETチームというものがあり、QAエンジニアとSET(Software Engineer in Test)が同じチームで品質を支えています。それぞれの役割については以下の記事をご確認ください。 tech.mercari.com リグレッションテストに関しては、全体の件数の約3

    メルカリのQAエンジニアがテスト自動化に挑んだ話 | メルカリエンジニアリング
  • Goで外部プログラムをexecするpackageのテストをどうするか

    とsongmuさんに教えてもらったことを参考に考えてやってみた方法を紹介します。あくまでも自分が考えた方法です。もっといい方法などあればぜひ教えてください。 まずテストの実行前に常に実行する処理を書きたいです。これは*testing.Mを使えばできます。 こう書くことでテストの実行前に setup 関数、全てのテスト終了時に clean 関数を実行できます。tmpのディレクトリ名を渡しているのはあとで解説します。それでは setup 関数と clean 関数はどうすればいいのかという話になりますが、その前にどういうテストを実行すべきかを考えてみます。 今回は外部プログラムの代わりに違うプログラムを実行したいのでそのプログラムを setup 関数で準備します。準備するプログラムは以下のようにしました。 起動したプロセスが突然死んだり、SIGTERMを送ってもなかなか死なないケースのパターンを

  • テストや開発環境における自動化に関して議論したICST2017 unofficial meetup - クックパッド開発者ブログ

    技術部品質向上グループの松尾(@Kazu_cocoa)です。 2017年3月13日〜2017年3月17日の間に、東京にてICST2017という国際学会が開かれました。 その学会に基調講演としてGoogleの方などが来日しました。そのさい、非公式ながらミートアップを開いたのでその時の学びを共有したいと思います。 ICST2017とは ICST2017とは、2017年に開催された第10回 IEEE International Conference on Software Testing, Verification and Validationの略です。Webサイトはこちら。 そこではソフトウェアテストや開発環境、品質に関する研究や事例が発表され、議論されました。 今年は10周年である上に、この会が始まって以来、初めて日で開催されたようです。 学会と聞くと学術的すぎると思うかもしれませんが、比

    テストや開発環境における自動化に関して議論したICST2017 unofficial meetup - クックパッド開発者ブログ
  • Gitでpushする前にテストが通る事を確認する - Tech Blog

    ようやく暖かくなってきて春が近づいてきた感がありますが花粉症が辛い時期のiOSチームのかっくん(@fromkk)です。 そういえば先日のtry! SwiftはTimersのiOSチーム全員で参加してきました。 面白いトークばかりでしたが頑張って英語で聞こうとしたばかりにあまり理解が十分に出来なかった箇所もあるので動画が公開されたら振り返りたいなと思っています^^; 昨晩サーバーチームの人達と話をしていて、稀に Syntax error が発生したコミットをプッシュしてしまい開発サーバーでエラーが出てしまう事があるという話を聞きました。 iOSでもビルドエラーだったりPushした後にCIでテストが通らなくてSlackでテストが失敗した旨を通知されると悲しくなりますよね。。 リモートリポジトリにPushする前にエラーチェック出来ないかなと思って少しトライしてみました! Git hookを利用

    Gitでpushする前にテストが通る事を確認する - Tech Blog
  • 開発効率を上げるテスト設計

    #phpblt6 ソースコード https://github.com/kazu9su/phpblt-6-example

    開発効率を上げるテスト設計
  • DockerとSeleniumGridとNightwatchでE2Eテストを始めよう - 文系プログラマによるTIPSブログ

    Dockerで簡単に始められますよ〜 Nightwatchならライトにサクッと書けますよ〜 皆さんはE2E(end to end)テスト、してますか? 今回はDocker、Selenium grid、Nightwatchを使ったE2Eテスト(ブラウザテスト)の環境構築からテスト実行、VNCでテスト実行の様子を確認するところまでやってみようと思います。 技術要素 なぜNightwatchなのか 環境構築 docker node.js for mac for windows テストの準備 dockerコンテナ git clone node_moduleの依存 nightwatchの設定 docker-hub Nightwatchでテストを実行する ローカルでテストする場合 Selenium Gridで並列テストする場合 dockerコンテナの起動 Selenium Gridの動作確認 Nigh

    DockerとSeleniumGridとNightwatchでE2Eテストを始めよう - 文系プログラマによるTIPSブログ
  • ふつうのユニットテストのための7つのルール - ブログなんだよもん

    最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記: テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記: もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定

    ふつうのユニットテストのための7つのルール - ブログなんだよもん
  • フロントエンドにテストを導入 - Qiita

    2016-8-8 ※webpack単体の記事を書きました。よろしければこちらもどうぞ step by stepで始めるwebpack 2016-5-16 ※karma単体の記事を書きました。よろしければこちらもどうぞ step by stepで始めるKarma 記事は画面のJavaScriptのテストとかまったくやったことない方 Mocha?webpackkarma?それぞれの解説記事はよく見るけど全体像がよくわからんという方向けです。(数日前の自分です) 全体を通して導入の流れを解説した記事があると全体像が理解しやすいのではと思い書いてみました。 前提 Nodejs,npm,chromeが導入済みであること 流れ Step 表題 目的

    フロントエンドにテストを導入 - Qiita
  • たった1人から始める社内テストコード文化

    # -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================

    たった1人から始める社内テストコード文化
  • テスト(コード)レビューの方針 書きなぐり版 - うさぎ組

    牛尾さんのブログをはてブったら、「じゃぁ、その手を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト(単体テスト)の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな?」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか?もしあったら記事にはります。」 僕のコメント「書いていません!」 僕のコメント「書きました!」 僕の主張 記事は僕の実験結果(経過報告)であり、

    テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
  • https://geechs-magazine.com/tag/tech/20160114

    https://geechs-magazine.com/tag/tech/20160114
  • ≡ ←ハンバーガーメニューのデザインでクリック率は違う(2014年のA/Bテストの結果から)

    スマートフォン対応サイトで右上や左上にある「≡」こんな形の三線のメニューはいわゆるハンバーガーメニューと言いますが、ハンバーガーメニューのデザインに関してA/Bテストを行っていた記事があったので紹介します。 ●ハンバーガーメニューのデザインパターンハンバーガーメニューは色々なデザインがあって、例えば以下の様なパターンがあります。(サイトイメージは「グラシン工房」から) まずはBootstrapの標準に近い形式。三の線があるだけのパターン。 次に三の線のしたにメニューという文字を配置して、アイコンの意味を説明するパターン。 三線を線(border)で囲い、ボタンらしく見せるデザインのパターン。 他にもいくつかデザイン・表現方法がありますが、それは前に書いた「【Web制作】スマートフォンサイトのメニューのアイコンデザイン・表示を比べてみた」の記事をご覧ください。 ●アイコンだけ・文字付

    ≡ ←ハンバーガーメニューのデザインでクリック率は違う(2014年のA/Bテストの結果から)