177bdf6352de463fdc87
経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの本。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー：データの破損などの心配が生まれる 応答が遅い：いらいら・二度と使わなくなる まとめてテストはダメ
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
単体テストについて - Qiita
一月ほど前に「テスト不要論」なるものが炎上しており、思うところがあったので、少しまとめてみました。 ご存じのとおり、テストにはブラックボックステスト・ホワイトボックステストがあります。 しかし、この二つの目的が大きく違うということを知らない人が多いのではないでしょうか。 ブラックボックステスト ブラックボックステストはコード実装者以外が行うべきものです。 コード実装者は書いてしまった以上ブラックボックスにはできませんし、 テストファストであっても頭の中にこれから書く実装が出来上がっていれば同様です。 ブラックボックステストは設計書通り（設計者の意図通り）にかけているのかという観点でテストし、品質指標とします。 別に設計書通りに書けば品質は高いなんて保障はないので、これを時間の無駄と考える人がある程度いるのではないかと思います。 しかし、プログラマの義務はブラックボックステストではなくホワイ
Angular入門: Component/ServiceをTestまで含めて試す - Qiita
import { Component } from '@angular/core'; import {CounterService} from './services/counter.service'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.scss'] }) export class AppComponent { point: number; constructor(private counterService: CounterService) { this.point = counterService.point.getValue(); counterService.point.subscribe((v) => this.p
Angular CLIによるAngular2入門 / Angular2アプリを爆速開発 - Qiita
ついにリリースされましたね、Angular2! Angular2にはCLI(command line interface)の開発環境が整えられており、雛形の自動生成、更新ファイルを自動ロードするなど、爆速な開発が可能になっていることをご存知でしょうか。 このAngular CLIを導入するだけで、様々な開発環境が一気に整います。そのため、gulpだgruntだ、TypeScriptだと様々な環境を整える必要があった今までの開発スタイルが一気に変わる可能性があります。 以下では、Angular CLIを使って共通ロジック[MessageService]からテキストを取得して、そのテキスト表示する画面部品、[HelloComponent]を持ったアプリを作りたいと思います。サービスやコンポーネントを使うのでAngularでの開発のおよその骨格を感じ取っていただけると思います。 では、Angul
Go言語を書くときにテスト駆動開発でやりたいなと思ったので、適当にテスト用のパッケージを調べてみた - Qiita
Go言語標準のtestingパッケージが個人的に使いづらかったのがきっかけ 個人的にカジュアルにTDDをしたかったので、PythonでいうassertEqualみたいなものが無いtestingパッケージが個人的に使いづらかったというだけです。(※筆者はPythonをよく使っています) 単なるユニットテストならgithub.com/stretchr/testify/assertパッケージが良いと思った これです。 https://github.com/stretchr/testify testifyパッケージの下にassert, http, mockパッケージがあって、それぞれ独立して使うことが出来ます。 importするときは、事前にgo get github.com/stretchr/testifyを行い、コード内部でこんな感じにimportすれば以下のように使えます。公式サイトの例のま
Go の Test に対する考え方 - Qiita
Go の Test に対する考え方 この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg
たった1人から始める社内テストコード文化
>>> $ py.test ../tests/test_webapi.py =============================================================================== test session starts =============================================================================== platform darwin -- Python 2.7.5 -- py-1.4.31 -- pytest-2.7.0 rootdir: /Users/*****, inifile: pytest.ini plugins: cache, django, pep8, pythonpath collected 2 items ../tests/test_webap
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CircleCIでLintとTestをParallel実行 - Qiita