たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
Nature Remo開発におけるテストフレームワーク『Catch2』の活用方法を紹介します - Nature Engineering Blog
3日目！ Nature Engineering Blog祭3日目は、ファームウェアエンジニアの中林 (id:tomo-wait-for-it-yuki) がお送りします。みなさま、自動テストはお好きですか？私は大好きです。手動で何度も同じことをテストするのは苦痛ですが、それをプログラミングのタスクに転化できるとなれば、最高ですよね！ 今回はNature Remoのファームウェア開発で使用しているユニットテストフレームワーク『Catch2』の活用方法を紹介します。ESP-IDFで使えるテンプレートプロジェクトも用意してありますので、少し長いですが、最後まで楽しく読んでいただけると嬉しいです。 Catch2 Catch2は (modern) C++で書かれたユニットテストフレームワークです。Nature RemoのファームウェアはC言語で書いていますが、テストフレームワークはC++で書かれたも
ユニットテストのガイドラインを作成しました | メルカリエンジニアリング
この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜Webエンジニアのキャリアを考える！
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 ソフトウェアのテストにおいて、最初のフェーズである単体テスト。若手Webエンジニアの中には、いきなり単体テストを任されて戸惑った方もいるでしょう。仕方なく現場で踏襲されているやり方に従っているだけ、ということもあるのではないでしょうか？ 今回は、単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 単体テストとは（各社ばらばらな単体テストの定義を再定義） コードベースの単体テスト 命令網羅（C0カバレッジ） 分岐網羅（C1カバレッジ） よくある（コードベースの）単体テストの間違い 機能単位の単体テスト 例：複雑なソート機能のテス
Go Conference'19 Summer in Fukuoka にて登壇、費用対効果のいいユニットテストの考え方と実践について話しました #gocon - BASEプロダクトチームブログ
こんにちは！BASE BANK株式会社 Dev Divisionでソフトウェアエンジニアをやっている東口（@hgsgtk）です！7月13日（土）に福岡で開催されたGo Conference'19 Summer in Fukuokaで登壇してきました。登壇内容や当日についてざっとレポートします。 Go Conference'19 Summer in Fukuoka - Go Conference'19 Summer in Fukuoka 登壇内容 Cost-effective Go unit test thinking and practices というタイトルで発表させていただきました。 個人的な観測では、Go界隈はユニットテストを書くことやテスタビリティの良いコードへの意識は強く、すでにユニットテストの技法に関する良資料はたくさんあるのですが、今回はWHYに着目した観点でプロポーザルを出
【Angular6】Jasmine + Karma で単体テストを書いてみた | DevelopersIO
どうも、福岡のmeです。 今回はAngular6で実装したSPAの単体テストをJasmine + Karma を使って書いてみたのでまとめました。 今回やること Jasmineというテストフレームワークを用いて記述したテストケースを Karmaというタスクランナーでコードが書き換わるたびに実行するようにします。 サンプルプロジェクトの作成 Angular CLIから新規プロジェクトを作成します。 ng new 今回使用したAngular環境は以下の通りです。 ng -v _ _ ____ _ ___ / \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _| / △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | | / ___ \| | | | (_| | |_| | | (_| | | | |___| |___
Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
Python の 単体テストで 大量の入力パターンを効率よくテストする方法 - Qiita
対象の読者 普段Pythonをお使いの方。 特に単体テストコードを書く機会がある方。 Python標準のUnitTestフレームワークを使う機会のある方。 概要 単体テストをする際、１つのテストケースの中で、パラメータを変えて複数回対象をAssertすることがあります。 普通に実装すると、１パターン失敗した時点で、残りのパターンがテストされず、テストは終了してしまいます。 Subtestを用いると、途中で失敗するパターンがあっても、テストを最後まで実行し、成否をパターン毎に個別に出力してくれるようになります。 前提条件 この記事の内容はPython 3.5系で検証したものです。 それ以前のバージョンだと想定通り動かないかもしれません。 テスト対象例 あるメソッドやクラスのテストをする場合、大抵の場合、テスト対象が取りうる入力、状態ないし結果を網羅するように、パラメータを変えてテストをするか
Pythonのテストのパラメータ化にはparameterizedを使うと楽（unittest/pytest/nose/nose2対応） - Blank File
Pythonでテストをパラメータ化した時の書き方を unittest と pytest を使った場合で紹介し、最後にそれらで使えるparameterizedというライブラリを紹介します。 ちなみに私はpytestよりもunittest派です。 はじめに テストを書いていると値が違うだけのケースを複数確認したくなる時があります。 例えば、1 + 1 = 2, 2 + 3 = 5, 32 + (-32) = 0, …などのようなケースです。 これをすべて別のテストケースとして書き下すのは面倒ですしメンテも大変なことになるので、テストフレームワークは大抵こんなテストが簡単にできる仕組みを提供しています。 今回はPythonでよく使われているunittest（標準ライブラリ）とpytestでこれらのテストの書き方を紹介します。 なんでいまさら？と思われそうですが、pytestはともかくunitte
Sprockets管理のJavaScriptを強引にユニットテスト - Money Forward Developers Blog
フロントエンドの石井と申します。 好きなゲームの種類はハクスラとローグライクです。 最近は Crypt of the NecroDancer に挫折して、Tales of Maj'Eyal へ河岸を変えました。 さて、弊社は Web アプリケーションのフレームワークとして主に Rails を採用しており、そのためブラウザで実行する JavaScript コードは、基本的には Sprokets （実際には sprockets-rails という Rails 用のインターフェース）を介してビルドされています。 この環境で、せめて各画面共通で使うモジュールにはユニットテストを書きたいと思い、Node.js 製ツール群の力を借りてそれを可能にしてみた、という話です。 ゴール Rails 4 デフォルト設定である、Sprockets と CoffeeScript による JS のビルドチェーンは変更
ユニットテストの歴史とテスタブルなコードについて - Qiita
自己検証コードの歴史 「自己検証コード」の黎明期は1992年のOOPSLAであるらしい ACMが毎年開催しているオブジェクト指向の国際会議である 誰かがここでのスピーチで「クラスは自分自身の検証コードを含んでいないといけない」と言ったそうである 「技術的負債」という言葉が歴史的に初めて使われたのもここでのことらしい wikiwikiを作ったカニンガムが使ったそうである ケント・ベックの「エクストリーム・プログラミング(1999)」、マーチン・ファウラーの「リファクタリング(2000)」の出版以降、一般に自己検証コードの重要性が広まることになる 「エクストリーム・プログラミング」は、従来のウォーターフォールモデルへのアンチテーゼであり、継続的なデプロイにより、品質の高いソフトウェアを作るテクノロジである そのためにはテストコードが必要なことが述べられている 「リファクタリング」は、技術的負債
タダでソフト開発の生産性と品質を上げる方法（4）：単体テストで威力を発揮する「MinUnit」
1．はじめに 出荷後、顧客サイトでソフトウェアのバグを出さないためには、開発中にたくさんバグをたたき出しておく必要があります＊1）。このためにはシステマチックなテストが重要で、通常は、モジュールレベルの単体テスト、ひとまとまりの機能をテストする結合テスト、システム全体を検証する統合テストの3段階構成で進めます。 今回は、これら3つのテストの中で最も数が多くて時間がかかり、ソフトウェア開発技術者が最も嫌う単体テストで威力を発揮するツール「MinUnit」を紹介します。MinUnitは、最小限の機能で大きな効果を期待できます。 ＊1）製品のテストが一通り完了し、「ほぼ正常に動作する」段階になると、「α版」として顧客に提供することがあります。α版をリリースする目的は、「正式版ではないが、お試しに使ってください。使い勝手に問題があったりバグがあったら教えてください。可能な限り対応します」です。 ソ
「ゲームプログラミングにユニットテストを導入する本」ＰＤＦ版を無料公開します - 土屋つかさの技術ブログは今か無しか
土屋つかさが書いた「ゲームプログラミングにユニットテストを導入する本」ＰＤＦ版を無料公開します。以下のＵＲＬからどうぞ。 ゲームプログラミングにユニットテストを導入する本（土屋つかさ著／Ｂ５／本文２６ページ） http://someiyoshino.main.jp/file/tsukasa/game_programming_and_unit_test.zip 本書は、２０１７年４月９日に開催される技術書オンリー即売会「技術書典２」にて頒布する予定の物のＰＤＦ版になります。 昨年末から延々やっていた司エンジンにテスティングフレームワークを導入する作業をまとめなおし、一般的なゲームプログラミングに対象を広げ、ユニットテストを知らないプログラマにも分かるように書き直した物です。短いのでさくっと読めるんでないかと思います。 調査時間が足りず書けなかったネタ（ファクトリーモデルとかＣＩとかより実践的
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
[iOS] ユニットテストの始め方 〜 テスト環境の作り方とXCTestの使い方 〜 | DevelopersIO
はじめに おばんです、あまりにもWebがわからなくて、知り合いのWebエンジニアに聞いたら嘘のようにすっきり理解できた田中です。調べてもわからないことは詳しい人を頼るとうまく返してくれるんだなあとありがたい想いでいっぱいです。 さて今回の記事は、最近テストについて学び始めたのでiOSでテストを始めるために最初に知っておかなければならない環境の作り方とXCTestに関する簡単な内容をまとめます。 検証環境 Xcode 8.2.1 テスト環境の作り方 テストターゲットの追加 プロジェクト作成時の指定方法 プロジェクトを作成する際に、テストターゲットも一緒に作成する場合は下の画像の Include Unit Test にチェックを入れてプロジェクトを作成します。 後からテストターゲットを追加する方法 既存のプロジェクトに後からテストターゲットを追加する場合は、 Xcode > New > Tar
![[iOS] ユニットテストの始め方 〜 テスト環境の作り方とXCTestの使い方 〜 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/cd616d43627770acf3d2af18695851272d60bed9/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F12%2Fios.png)
一から始めるJavaScriptユニットテスト - Hatena Developer Blog
この記事は、はてなエンジニアアドベントカレンダー2016の5日目の記事です。 こんにちは、はてなでアプリケーションエンジニアをしている id:shiba_yu36 です。先日、buildersconにおいて、現在所属しているプロジェクトでJavaScriptのユニットテストを導入した知見について、「一から始めるJavaScriptユニットテスト」というタイトルで発表しました。 speakerdeck.com この発表は、実際にJavaScriptのユニットテスト環境を作ってみると非常にハードルが高いと感じたので、そのハードルを少しでも下げられればという思いで、非常にシンプルな例で一から環境を作る例を紹介しました。アジェンダは次のとおりでした。 カクヨムのJS環境 JSのテストツールを整理する 通常の関数のユニットテスト DOM操作する機能のユニットテスト カクヨムのJS環境や、JSのテスト
ユニットテストの実行環境を用意して Visual Studio Code のエクステンションを快適に TDD する - Qiita
こんにちは @ryu1kn です。これは Visual Studio Code Advent Calendar 2016 の２日目の記事です。 Visual Studio Code (以下 VS Code) はバージョンが１に届いた頃からメインで使うようになりました。以降いくつかエクステンションを書いたのですが、今回はそれらのエクステンション開発時に必要だったユニットテストの環境準備について書きます。 TL;DR エクステンション生成時についてくるテストの実行環境は VS Code の全 API が使えるインテグレーションテスト用のものであり、起動が遅く TDD でのユニットテストには向かない コマンドラインから手早くユニットテストを実行できるようにしておくと快適に TDD できる VS Code の API を提供する vscode モジュールは、エディタ上で実行する時とコマンドラインか
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unit Testing in a Nutshell - DroidKaigi 2018
GitHub - rylnd/shpec: Test your shell scripts!
