単体テストの考え方/使い方を読んだ。読んでよかった。 - Mitsuyuki.Shiiba
読んでよかった book.mynavi.jp 評判通りよかった そっかーなるほどなぁ。面白いなぁ。と思うことがいろいろあった とはいえ、著者の主張全てに同意というわけではなく「著者はそう考えるんだな。自分は違う考えだな」と考えさせられる部分もいくつかあった 苦手な部分もあった 古典学派とロンドン学派に分けて話を展開しているのはあまり好きじゃないなと思いながら読んだ 定理やマトリクスに当てはめて話を展開する部分があって、いくつかは無理やりだったり話をややこしくしていたりするように自分は感じた。そういう部分は苦手だなぁと思いながら読んだ というのが全体の感想。内容はとてもよかったし、苦手な部分もそれはそれで考えさせられたので、読んでよかった。ってことでパラパラめくりながらメモを書いていこう あらためて意識したい2本 「第4章 良い単体テストを構成する4本の柱」の中の2本が、当たり前のことではあ
たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - 電通総研 テックブログ
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 この記事では、VS CodeのDev Containerを使ってOSに依存しないPythonの開発環境を構築する方法をステップバイステップで丁寧に説明します。 VS Codeの利用経験があり、またPythonによるアプリケーション開発に興味のある方を想定読者として記述しています。Pythonの初心者から中級者向けを意識して書いていますので、意図して冗長な説明をしています。 すでにPythonによるアプリケーション開発に十分に詳しい方は、まずはまとめだけ読んでみてください。私自身それほどPythonのエコシステムに詳しいわけではありませんので、知識の抜け漏れは恐らくあるでしょう。そういった事に気が付いたら、XなどのSNSでこの記事のURLを付けてコメントをしていただけると幸い
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜Webエンジニアのキャリアを考える！
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 ソフトウェアのテストにおいて、最初のフェーズである単体テスト。若手Webエンジニアの中には、いきなり単体テストを任されて戸惑った方もいるでしょう。仕方なく現場で踏襲されているやり方に従っているだけ、ということもあるのではないでしょうか？ 今回は、単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 単体テストとは（各社ばらばらな単体テストの定義を再定義） コードベースの単体テスト 命令網羅（C0カバレッジ） 分岐網羅（C1カバレッジ） よくある（コードベースの）単体テストの間違い 機能単位の単体テスト 例：複雑なソート機能のテス
Ruby 2.6 新機能：本番環境での利用を目指したコードカバレッジ計測機能 - クックパッド開発者ブログ
技術部の遠藤（mame）です。1 ヶ月くらい風邪が直らず、苦しみながらこれを書いています。 昨日は Ruby 2.6 の NEWS を裏話付きで解説する記事を書きました（プロと読み解く Ruby 2.6 NEWS ファイル）。今日と明日は、その中でクックパッドのフルタイムRubyコミッタが主に担当したところを少し詳しく紹介します。 今日は、遠藤が作った "oneshot coverage" と言う 2.6 の新機能を紹介します。 背景：Ruby では不要コードの発見・削除が難しい クックパッドのサービスの多くは、cookpad_all という 1 リポジトリからなる、巨大な Rails アプリケーションとして実現されていました。しかし、このやり方ではメンテナンスが限界になってきたので、「お台場プロジェクト」という大整理プロジェクトが行われてきました。この辺の詳細は次の 2 つの記事が詳しい
特定のファイルに対して一定のテストカバレッジを保証する - Islands in the byte stream
ある特定のファイルのテストカバレッジが、ある特定のテストファイル（群）を実行したときに一定のカバレッジ率であることを保証したいと思うことはありますか？私はあります。 そこで、 次のような spec/coverage_helper.rb を用意して、 spec/rails_helper.rb などから require すると、 COVERAGE_ASSERTION=app/models/ability.rb rspec spec/models/ability_spec.rb:99 のようなコマンドをCIで実行したときに一定のテストカバレッジ以下のときにCIがコケるようにしました。 # frozen_string_literal: true class CoverageAssertion class CoverageAssertionFailure < StandardError end at
pythonのdoctestとcoverageでコメントの説明の十分性を簡易確認 - 千里霧中
pythonでは、ドキュメントとして書かれたコメントと、実際の動作が一致するか確認する手段として、doctestを標準で提供しています。 題材として、大まかな動作の説明をdocstringに書いた、以下のhoge()という簡単なメソッドを扱います。 # coding:utf-8 # sample.py import re def hoge(line): ''' 指定した文字列から定数名の定義を抽出する # (1)プリプロセッサのマクロ定義名を抽出する >>> from sample import hoge >>> hoge('#define PREPRO_MACRO 33') 'PREPRO_MACRO' # (2)const変数の名前を抽出する >>> hoge('const int const_variable_name = 33;') 'const_variable_name' ''
JUnitをバッチ実行してカバレッジも取得する方法 - Qiita
はじめに 自分へのメモ的な意味合いも兼ねて書きます。 私はまだSE歴も浅く技術力も知識も未熟なため、間違っているところがあるかもしれません。 もし間違っているところがあれば、指摘していただけると嬉しいです。で、できれば優しく。。 ＜前提条件＞ ・Windows10 64bit ・Java7 ・eclipse Version: Luna Service Release 2 (4.4.2) 以下のプラグインがインストール済み ・junit ver 4.12 ・maven 4.0.0 ・EclEmma 2.3.3 ・Hudson/Jenkins 1.4.0 １．jacocoをMaven依存関係に追加する。 ・pom.xmlファイルに以下の文を追加 <!-- jacoco --> <dependency> <groupId>org.jacoco</groupId> <artifactId>jaco
Go の CI で lint と カバレッジ回して非人間的なレビューは自動化しよう in 2016年 - haya14busa
この記事は Go (その3) Advent Calendar 2016 の24日目の記事です(代打)． メリークリスマス! 本記事では Go 言語プロジェクトの CI で回すと便利な各種lintの紹介やカバレッジ計測の方法などなどについて紹介します． Go 言語おすすめ linter Go の lint 一覧といえば gometalinter じゃん? みたいな話もあると思うのですが，CIで回すには個別に linter を明示的に回すほうが良いかと思います． ということで 僕が普段使ってるオススメ linter の紹介です． go vet vet - The Go Programming Language おすすめ度: ★★★★★ Vet examines Go source code and reports suspicious constructs, such as Printf ca
Karma + Coveralls で行う webpack プロジェクトのテスト - SmartNews Engineering Blog
はじめに みなさまはじめまして、SmartNews の井口（いのくち; @kainoque）と申します。主にサーバサイドおよび各種管理コンソールの開発を行っています。弊社における開発案件はネイティブアプリおよびそのバックエンドである各種 API サーバに関するものが大半です。一方で、社内・社外向けの各種管理画面については、Web フロントエンドに関する開発も行っています。今回は、フロントエンド開発の話題として、掲題のとおり、webpackプロジェクトのテストにまつわるあれこれをお話します。 TL;DR SmartNewsでは Web フロントエンド開発においても品質向上に取り組んでいます Karma を用い webpackプロジェクトをテストしています コードのカバレッジもばっちり取得しています Coverallsを使ってカバレッジを共有、管理しています 背景 筆者は、SmartNews
Ansible向けのコードカバレッジツールKirbyを作りました - Soon Lazy
PythonやJavaでコードを書く場合、コードカバレッジの測定は、よくやりますよね。最近、Ansibleでもコードカバレッジを測りたくなったのですが、それらしいツールがなかったので、作ってみました。名前はKirbyです。今回はKirbyがどんなツールなのか紹介してみます。 ks888/kirby · GitHub どんなことができるのか Kirbyは、AnsibleのPlaybookやRoleに対して、タスクレベルのカバレッジを測定するツールです。 例えば、次のようなPlaybookと、Serverspecのテストがあったとします。Playbookでは2つのタスクを実行しています。Serverspecのテストでは、Playbookの一つ目のタスク（create dir1）に対するテストをしています。 ~/src/kirby_demo% cat create_2dirs.yml --- -
How to implement testing + code coverage on React with Karma, Babel, and Webpack
I’m writing this article because of the difficulties I faced when I was tasked with setting up testing on my companies React powered UI. If you’re looking for a step by step process to getting your testing running using Karma, and Karma’s coverage plugin, with Babel and Webpack all working nicely together and returning production code coverage metrics (rather than transpiled code), then read on. O
GitHub - yahoo/preceptor: Test runner and aggregator
##What is Preceptor? Today, there are a lot of testing frameworks out there, many of which are optimized for testing specific areas. A couple of these frameworks are: Mocha - The most popular unit-testing tool (according to NPM downloads), testing each individual unit/component of a system in isolation. Cucumber - A high-level acceptance testing tool that tests features through scenarios, giving p
リスクとコストのバランスを考慮したテストカバレッジ - ワザノバ | wazanova
https://www.youtube.com/watch?v=rbWUxRNawIw 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Rocky Mountain Ruby 2014で、Pivotal LabsのArjun Sharmaは、「用意したテストケースで、自信をもってデプロイできるのか？素早く不安なくリファクタリングができるか？」という条件を満たすには、コードのリスク程度に見合ったテストタイプを選択することを勧めています。 まずは、テストカバレッジ分析ツールについて、 良いカバー率というのは要注意。それをどう解釈するか。カバレッジの定義がツールごとに異なる可能性や、書き忘れたコードやアサーションはチェックできないことを考慮すると、単純に目標のカバー率を達成したからこのアプリは大丈夫というこ
Jenkinsで収集したカバレッジの変化情報をSlackに投稿する - Qiita
mokemokechicken氏の gitでPushする度にKarma-CoverageのCoverageの値をJenkinsで計測し、その増減をIdobataに投稿する に触発されて、最近自分のチーム内情報共有に活用している Slack でもやってみました。 Gitlab + Jenkins + 何かしらのCoverage + Slack という組み合わせになります。 ここでは JenkinsでNode.jsのテスト＆カバレッジレポートを管理する で出力したカバレッジ情報を使っていますが、Cobertura形式であればプロジェクトの言語は問わないはずです。 できること gitのcommit treeを考慮した上で前回のカバレッジ結果からの変化を計算し、増加・変化なし・減少の3パターンの報告をSlack上の指定のchannelに投稿します。 「Open」の部分はJenkins上の特定ビルド
grunt+istanbul+mochaでNode.jsのテスト＆カバレッジ計測を行う - Qiita
単体テストの件数や可否ももちろんですが、コードのカバー率も可視化されることで、品質向上の1つの指標にもなります。 Node.jsで開発しているプロジェクトについて、こういったデータをgruntタスクで簡単に生成できるようにしましょう。 仕組みとして使うものは以下のとおりです。 grunt: JSタスクランナー mocha: JSテストフレームワーク chai: BDD/TDDアサーションライブラリ sinon: Spy,Stub,Mockライブラリ istanbul: コードカバレッジ計測ツール gruntは既に導入済みで、活用している前提とします。 JSのテストはJasmineが有名ですが、自由度の高いmocha+chai+sinonが個人的にはお気に入りなのでこちらを使います。 コードカバレッジ計測はいくつかの選択肢がありますが、メソッドや行、分岐等を計測できるistanbulを使いま
JenkinsでNode.jsのテスト＆カバレッジレポートを管理する - Qiita
grunt+istanbul+mochaでNode.jsのテスト＆カバレッジ計測を行う の続きになります。 ローカルでテストを実行するだけでなく、Jenkinsのジョブとして設定することで、テスト結果やカバレッジ計測結果を集計管理できるようになります。 プロジェクトの経過を追うことができるようになり、より便利になります。 関連パッケージのインストール mochaからJenkins用のテスト結果レポートを出力するために、mocha-jenkins-reporterを入れます。 また、このreporterは出力先ファイルの指定に環境変数JUNIT_REPORT_PATHを参照するので、gruntタスクで指定できるようgrunt-envも一緒に入れておきます。 gruntタスクを設定する grunt+istanbul+mochaでNode.jsのテスト＆カバレッジ計測を行う で設定したタスクを修
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
My standard tox.ini file that allows you to run coverage, lettuce, nosetests and lint, and to pick out a given feature or a module for nosetest (So that you don't have to run the whole suite)
GitHubを快適にブラウジングするための3種の神器
Analyzing coverage of R unit tests in packages – the {testCoverage} package | R-statistics blog