正常系テストでチェックすべき項目留意点メモ - 憧れ駆動開発
テストコードを書く上での留意点メモ - AtAsAtAmAtArAの続き 前提としては「あるWebAPI」で、どうやって網羅的に正常系テストをどう書くか。そんなときの留意点メモ。 リクエスト条件で条件が分岐する可能性があるなら、それをテスト getで取得できればいいものは基本的に200が返るテストがあればよい ただし取得したレスポンスによって条件分岐するならそれはテストする post関係も基本は200が返るテスト 登録なら登録が正常に行われているかのテスト 変更なら変更が正常に行われているかのテスト 削除なら削除が正常に行われているかのテスト あとは仕様ドキュメントを見てその他例外や特定の条件があったらそのコードを加える、でしょうか。
Autodoc - r7kamura blog
闇Advent Calendar 1日目の記事として、最近の開発における心の闇に触れます。 最近開発した Autodoc というツールについて簡単に説明した後、 この手のツールの開発にあたって考えていた、 創作活動の在り方や、社会の斥力、25歳定年説などについて触れようと思います。 Autodocとは Rack applicationで実装されたAPIに対して、RSpecで書かれたテストを元にAPIドキュメントを生成するもの。 テストを実行すると、テスト中に発行したリクエストやレスポンス、そのテストに付けられたメッセージを元に、 良い感じに情報をまとめ、Markdown形式でAPIドキュメントを記したファイルを生成してくれる。 例えばGitHubではMarkdownファイルを適当に描画してくれるので、 下図のようにGitHub上で簡単にドキュメントを閲覧出来るようになる。 テストの書き方
パラメータの正当性検査とユニットテストのカバレッジ | DevelopersIO
渡辺です。 最近はユニットテストの導入方法などに関するエントリーが多かったので、今回は実用的な小ネタとして、メソッドにおけるパラメータの正当性検査とユニットテストについて紹介したいと思います。 パラメータの正当性検査 はじめにパラメータの正当性検査について復習しましょう。Javaプログラマであれば読んでないことが許されないEffective Java（第2版P.175、ただし絶版）には次のように記述されています。 ほとんどのメソッドとコンストラクタは、パラメータとして渡される値に関して何らかの制約を持っています。たとえば、インデックス値が負であってはいけないとか、オブジェクト参照がnullであってはいけないというのが普通です。このような制約は明確に文書化すべきであり、メソッド本体の初めに検査することで制約を強制すべきです。これは、エラーが発生したらできるだけ速やかにエラーを検出するようにす
ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと ｜ Developers.IO
ドキュメントベースの単体テスト ソフトウェア開発では、テストケースをExcel等で管理し、テストをテストフェイズで実施する方式（以下、ドキュメントベースの単体テスト）が行われてきました。 ドキュメントベースの単体テストでは、テストフェーズが明確に切られています。テストフェーズでは、テスト担当者がテストを実施し、結果をドキュメントに記録します。必要に応じてエビデンスも残すでしょう。もし、テストが失敗したならば、不具合管理票（バグ票）を起票します。そして、不具合の原因を分析し、仕様書やソースコードを修正します。不具合が修正されたならば、もう一度テストを実行し、不具合がなくなるまでこのサイクルを繰り返し、品質を高めていきます。 このようなドキュメントベースの単体テストは、機能や画面を対象としています。そして、ほとんどの場合は品質保証を目的としています。テスト件数や不具合件数、不具合の発生原因や修
Excelなんかの試験（テスト）仕様書とJunit等のユニットテストの関係（その１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） Excelなんかで、試験仕様書（テスト仕様書）を書くことって、多いと思います。 で、Junitを使う人も多いと思います。 でも、やっぱ、この業界、流派ごとの争いがおおいんでしょーかねー、 このExcelなんかで書く、試験仕様書（テスト仕様書）が、Junitで、どうやって、落とし込むのかっていうことについて、書いてくれてないケースって、多くありませんかねー。 ウィリアムのいたずらの関係したプロジェクトだけが、不運にも、そうなのか？ （たしかに、「不幸学鑑定」をやったら、けっこう不幸な人です。で、その不幸の度合いは、ドラゴンボールで言うところのヤムチャ級と出た）。 っていうことで、今日は、その関係について、独断と偏見で書いてみたいと思います。 （つーことで、これと違う意見を言う人も、
Excelなんかの試験（テスト）仕様書とJunit等のユニットテストの関係（その２） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前のブログで書いた Excelなんかの試験（テスト）仕様書とJunit等のユニットテストの関係（その１） の続きです ■■ 前のブログの内容 「そもそも、試験仕様書に書く項目を考える」では、仕様書に書く内容について書いて、とくに ・テスト内容 ここが、２つないし、３つにわかれる場合もある ３つの場合は、テストの内容、テストを行う（前提）条件、予想される結果 ということを書きました 「Junitなんかのユニットテストの考え方について、考えてみる」では、Junitなんかが、契約による設計（DbC）にもとづいていて、設計内容（＝テスト内容）は、事前条件、事後条件、不変条件にわけられるという話をかきました。 それらのことの詳細は、こちらをどうぞ http://www.javaroad.j
Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計の話
github を用いた開発フローテンプレート
GitHub Organization: Issues+Pull Requestでチケット駆動開発する手順 - Qiita