テスト仕様書がExcelで何が悪い - うさぎ組
僕もExcelでテスト仕様書を書くのは嫌なときがあります。全員OrgMode使えば幸せなのに！！！って何度思い、CucumberのフィーチャファイルはOrgModeから書けないという点をのぞいてすばらしいとか思っています。 でも、Excelのテスト仕様書をすごく嫌う人って、たいていはその人が使っているフォーマットがすごく気に食わないだけな気がしています。 なんでそう思うかって言うと、「さぁテストケースを書いて僕に見せてよ」とか言うと、8割くらいのひとはスプレッドシートをつかっています。（僕の勉強会観測範囲）その人たちがExcelのテストドキュメントをいやがっているかどうかは未だにわかっていませんが、結局使いやすいから使っているんじゃないでしょうか。 なので、「こういったフォーマットがいやだー」っていうのはわかるけど、でもスプレッドシート使いやすいんでしょ？とか、じゃあ、きれいなテストドキュ
「JBehave」による振舞駆動開発（BDD）の実践
対し、今回紹介するBDD（behavior driven development：振舞駆動開発）では、テスト対象の振る舞いに対してのテストを記述します。BDDでは、要求仕様にフォーカスし、よりWhatを意識したテストケースを作成できます。これにより、TDD以上に設計から実装へのトレーサビリティを確保できるようになります。 対象読者 Java開発者 必要な環境 JDK 7 Maven 3 JBehaveとは JBehaveを利用することにより、JavaでBDDを実践できるようになります。具体的には、storyファイルに記述した要求仕様をベースに検証ロジックを実装し、テストを行います。 事前準備 まずは、Mavenで空のJavaプロジェクトを作成します。以下のようにコマンドプロンプトでmvnコマンドを実行します。 <project xmlns="http://maven.apache.org/
テストをどこまで書くか - はこべにっき ♨
CROSS2014で以下の2つのセッションにお招きいただきお話をさせていただいた。ありがとうございました。 http://www.cross-party.com/programs/testcidevops/ はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey 2014/1/17 #cross2014 現場に聞く！テスト/CI/DevOps、実際のところどうなの - Togetterまとめ http://www.cross-party.com/programs/butsukari/ 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetterまとめ セッション中はもちろん、その後の懇親会でもいろいろな方におはなしを伺えてかなり勉強になった。テストやコードレビ
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
ユニットテスト改善ガイド | DevelopersIO
先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
Chaining Assertion for MSTest
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
テストがなぜうまくできないか
■テストが重要であることは，大体開発に携わる人間ならだれでもわかっていることです。しかし，実際の失敗したプロジェクトの結果をみると，まず１００％プロジェクトのあらゆる時点でテストがおろそかになっています。 答えは簡単で，テストしている余裕が無いということです。つまり，徹夜続きでプログラムを開発して納期になんとか間に合わせたいとなると，どうしても手を抜くのがテストになってしまいます。（だいたいわかっちゃいるけど・・・ということになってしまいます） プロジェクトの成果物であるシステムが期待通りの効果を出すためには，品質面をクリアしている必要があります。リッチＰＭ・ライトＰＭどちらの道筋を取る場合も，実は一番重要でクリアしなければならないものがテストです。 そもそもテストとはなんでしょう。 テストとは「できあがったシステムが正しく目的通りに動作するかどうかを検査すること」に他なりません。 まずテ
privateメソッドのテストについて
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
循環的複雑度 - Wikipedia
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。プログラムのソースコードから、線形的に独立した経路の数を直接数える。 手法としてではなく、そのコンセプトは文章の可読性（複雑度）を測定する Flesch-Kincaid Readability Test に似ている。 循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。
Google Testをインストール、しないですませる方法 - エンジニアのソフトウェア的愛情
久々にGoogle Testネタ。 以前ちょっとふれて宿題としておきながら放置していたことを思い出したので、そのフォロー。 fused source files are included. バージョン1.5.0の時点で新機能（？）として「fused source files」が追加されています。先のエントリを書いた時点では調査不足でわかっていなかったんですが、名前から予想したとおり、「コピーしてincludeてコンパイルしてリンクすりゃOK」というものでした。 Fusing Google Test Source Files 現在最新のリリースである1.6.0のzipファイルを展開すると「fused-src」というフォルダがあり、その中に「gtest」というフォルダがひとつだけ入っています。 gtest-1.6.0/ fused-src/ gtest/ このフォルダの中に行数が約2万行の「g
オブジェクト指向プログラミングにおける単体テストのしかた - masateruk’s blog
この記事は TDD Advent Calendar 2012 の最終日の記事です。前日の記事は@biacさんの「[コラム] テストファーストとは何か?: TDD.NET」、初日の記事は@sue445さんの「Try Dream Development : 夢の開発を始めよう #TddAdventJp - くりにっき」です。 TDD Advent Calendarの記事なのですが、TDDというより単体テストの話です。単体テストのやり方について人それぞれやり方があるかと思いますが、自分が単体テストをするときの手順をまとめてみました。以下がその手順です。 テストするメソッドを決める。 メソッドの仕様を確認する。 事前条件をいくつかに場合分けする。 上で分けた場合ごとに、テストケース用のメソッドをつくる。 テスト対象のクラスのインスタンスを生成し、場合分けしたひとつの事前条件を満たすコードを追加する
メソッド名を日本語にする話 - 日々常々
Javaでもメソッド名とか*1に日本語が使えます。使えない文字*2もありますけど、とりあえず置いておきます。 public void あいうえお() { // なんか書く } 流石にプロダクトコード*3で日本語メソッド名などを使う事はまずありませんが、テストコードで書くと言う話は結構聞く所ですし、それなりの効果もあります。 @Test public void あの条件であれやったらああなると良いな() { // なんかテスト } 日本語メソッド名は、いちいち日本語入力に切り替えないといけないとか、呼ぶときは面倒だったりしますが、テストメソッドのように呼び出しを書かないものなら特に問題無いと思います。 日本人なので日本語で何かを書くと、それなりの意味が自然に入ると思います。少なくとも日本語で書けば、テストメソッド名が「hoge」とか「test」とかになる事はありませんし、「テスト」なんてもの
状態のあるコードに対するテストの自動生成 - 西尾泰和のはてなダイアリー
BLUE*アルゴリズムを実装してみたので、せっかくだからテストの自動生成をやってみた。 今回テスト対象にするコードの仕様は 開く、閉じる、書き込む、の3つの操作ができる 開いてないのに書き込んだり閉じたりしたらエラーになる というもの そしてこちらがそれの「バグのある実装」： class Target(object): # bad impl. def __init__(self): self.opened = False self.closed = False def open(self): self.opened = True def write(self): if not self.opened: raise RuntimeError if self.closed: raise RuntimeError def close(self): if not self.opened: rais
QuickCheck++: Main Page
Table of Contents Introduction What is QuickCheck++ Why Would I Want to Use It? How to Get It? Relation to Haskell's QuickCheck License Using QuickCheck++ Defining Properties Verifying Properties Specifying a Precondition Inspecting Input Data Distribution Custom Data Generators General Purpose Generators Special Purpose Generators Data Generator Primitives Printing Property Names Verbose Checking
QuickCheck - Wikipedia
QuickCheck is a software library, specifically a combinator library, originally written in the programming language Haskell, designed to assist in software testing by generating test cases for test suites – an approach known as property testing. It is compatible with the compiler, Glasgow Haskell Compiler (GHC) and the interpreter, Haskell User's Gofer System (Hugs). It is free and open-source sof
Haskellの単体テスト最前線 kazu-yamamoto/unit-test-example · GitHub
#Haskellの単体テスト最前線 [To English] これはHaskell Advent Calendar 2012の5日目の記事です。 Haskellで作成したパッケージに対して、単体テストを書くための最新情報をお届けします。以下の記事では、Haskell Platform 2014.2.0.0 以降を使うことを前提とします。 ##要約 要点は4つです。 利用者に見せたい振る舞いは、doctest で書く 利用者に見せたくない振る舞いは、hspec で書く テストを自動化するフレームワークとしては Cabal を使う doctest でも hspec でも、純粋なコードに対しては、できるだけ QuickCheck などの性質テストを書く この記事で一番伝えたいのは、3) です。例題としては、Base64 という符号化を取り上げます。Base64 は知っていると仮定して話を進めます
COVTOOL - Free test coverage analyzer for C++
file statements A file statement begins with a file: tag and its associated fields. It is then followed by one il: clause and at most one el: clause with their associated fields. The log file is a collection of file: statements ending in a totals: statement. Here is an example: file: /home/dir/file.c 6 3 50 el: 1 2 6 il: 1 2 3 4 5 6 totals: 6 3 50 In this example, only one file was instrumented, "
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUnit4のassertThat()って便利なの？
