FileMakerのテスト手法を少しでもマシにしようと、一番可能性の有りそうなカスタム関数のユニットテストを試みました。 ファイル FMCFUnit.zip ファイルはパブリックドメインに置きます。 仕様 なるだけシンプルな構成を試しています。 テーブル・TO テストを取り扱うテーブルに、テストケースをレコードとして登録。テストケースは分類用のsuiteと評価式のtestcase、結果のstate、並び用のorderを持ってます。 TOは、メインのものと、suiteをまとめる用の自己リレーションだけ。 アサーション アサーションは、「FMCFUnit_Assert」プレフィクスのカスタム関数として登録。基本的なアサーションは1つのカスタム関数にしようかとも思ったけど、testcaseからの指定も実行処理もややこしくなりそうだったので、やめ。独自のアサーションも単なるカスタム関数として登録。
世界最大級のアジャイル開発の祭典「Agile 2018」がアメリカのサンディエゴで開催されました。日本でもめずらしくなくなってきたアジャイル開発ですが、北米で開催されるこのイベントには、2000人を超える開発者、テスター、プロダクトマネージャ、プロジェクトマネージャなど、ソフトウェア開発に関わる人達が世界から集まってくるカンファレンスです。本稿では、「Testing & Quality」トラックのセッションを中心にレポートします。 ebayのアジャイルテスティング UKのebayでHead of Software Testingとして活躍するDan Ashby氏のセッション「Testing in Agile」はその名のとおり、「アジャイル開発におけるテスト」を集約した内容でした。 ソフトウェアテストとは何か? さまざまな解答がでてくる問いですが、一般的な解答は以下のようなものがあるはずです
テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか?」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか?少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか? カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか? (テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
The Difference Between TDD and BDD If you keep up-to-date with the latest software development practices, odds are you have heard of Test-driven development (TDD) and Behavior-driven development (BDD). This post is meant to explain what each practice means, provide examples, and then contrast the two. Let’s dig in and see what we learn. Test-Driven Development When I first heard about TDD, the ide
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か?中心から排除したい要素は何か?を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装(特定のデータベース種類やSQLなど実装詳細)は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
http://studiototoro.com/musukarakka-471より改変前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。 象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。 今回は、アジャイルテストの4象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。 テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、
PowerMock + Mockito を簡単に使ってみたのでメモを残しておきます。 やったこととしては、 1. static メソッドのモック化 2. private メソッドのモック化 3. 例外投げるメソッドのモック化 4. コンストラクタのモック化 という感じです。 今回は、Maven 使ってやることにしました。pom.xml の記述内容は以下に。 ・Mockito_maven - powermock - PowerMock is a Java framework that allows you to unit test code normally regarded as untestable. - Google Project Hosting https://code.google.com/p/powermock/wiki/Mockito_maven ※ 以下から .jar をダ
SWETの薦田(@toshiya-komoda)です。 今回は第3回目の記事で言及させていただいた機械学習とUIテストに関して実験的に進めている技術開発について紹介させていただこうと思います。 この記事で紹介している内容の実装はGitHubにアップロードしていますので、もし興味がある方はこちらも覗いてみていただければと思います。 こちらはTensorFlow Advent Calender 2017第7日目の記事にもなっています。機械学習の実装の中でKerasを用いてます。 とりあえずデモ 最初に以下のデモ動画をご覧いただきたいです。会員登録フォームに対する自動テストのデモです。各入力欄に適切な情報を入力しつつ、パスワード欄にだけ'weak'という不正なパスワード文字列を入力して、バリデーションで弾かれることを確認するテストです。デモでは入力欄に値を埋める部分を、Chrome Extens
最近Appiumを触り始めた@toshiya_komodaです。今回は、Appiumを用いたテストコード開発を支援するAppium Studioというツールを触ってみたので紹介させていただきます。 TL;DR Appium StudioはGUI操作だけでテストケースを作成・編集でき、プログラミングに習熟していない人でもAppiumを使ったテストケースの作成ができそう。 ただしまだ動作が不安定なところがあり、今後の安定性向上に期待! Appium Studioとは Appium Studioは、Appiumを用いたE2E自動テストの統合開発環境(IDE)として開発されており、無料でも全てではないですが豊富な機能を利用することができます。 AppiumのGUIツールといえば、Appium Desktopを思い出す方が多いかと思いますが、Appium Desktopと何が違うのでしょうか? Ap
まえがき E2Eテストを自動化したいこと、あると思います。 特にアジャイル開発を行なっていく際には、予期せぬregressionを防ぐためにも必須のツールでしょう。 毎回ポチポチポチポチ画面テストするのは工数的にもモチベーション的にも最低です。 そう考え、私はSeleniumによる自動テストを1ヶ月かけて設計・実装しました。 そして最初は「ぬるぬる自動操作されてて感動した😆」「これで工数めっちゃ削減されるな👍」 そんな声をチームメイトからもらえ、「いいもん作ったな〜俺」とか内心ドヤ顔でした。 ただ数ヶ月もしない内にテストは役立たずになってしまいました。 この記事はなぜ自動テストが無価値になってしまったのかを書きます。 割とSeleniumあるあるな話でもあるので、これからSelenium使おうという方の参考になれば幸いです。 ※ちなみに私はJS(+ WebdriverIOというライブラ
この記事は、「Speee Advent Calendar 2016」の6日目です。 iosアプリエンジニアはテスト1を書かない? TDDやテストコードを書く重要性が叫ばれて久しいですが 日々業務でiosアプリ2のコードを書いていると中々テストを書く機会がありません。 また、社外のエンジニアの方とお話させて頂いても、あまり積極的にテストを書くプロジェクトは少ないように感じます。 この記事ではiosアプリでテストを書かない(書きづらい)理由と、それを突破してテストを書くにはどうすればいいかを考えてみます。 UIのテスト XcodeにはUIテストツールが含まれています。 コードベースで動作を指定して画面操作をシミュレートすることが可能ですが あまり有効に活用できている現場は無いように感じます。 おそらく問題点は2つあって 一つ目はシミュレータの動作の遅延などによって再現性の低いバグを引き起こすこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く