Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 作者: 秋山浩一出版社/メーカー: 日科技連出版社発売日: 2010/10メディア: 単行本購入: 7人 クリック: 153回この商品を含むブログ (19件) を見る 『知識ゼロから学ぶソフトウェアテスト』読んだ - ✘╹◡╹✘ を書いたところ、知り合いのテストエンジニアにこれオススメだよと勧めてもらい『ソフトウェアテスト技法ドリル』を読んだ。読みながら、どこでテストを書くのを満足すれば良いのか、このトレードオフはどんな条件下でどういう状態になるのか、テストについて常に信じられるものは何なのか、ということを考えていた。 なんでテスト書いてるのか まあ四年前の本なのでググればレビューも沢山出てくるしとりあえず本のことは置いといて、テスト書くときにいかに雑な仕事してるかという話でもしたい。日々コードを書いていると、たまに「なんでテスト書い
知識ゼロから学ぶソフトウェアテスト 【改訂版】 作者: 高橋寿一出版社/メーカー: 翔泳社発売日: 2014/01/08メディア: Kindle版この商品を含むブログを見る 値下がりしていたので『知識ゼロから学ぶソフトウェアテスト』読んだ。親しみを持ってもらおうという気持ちで所々に暴言が入っているのがウケる。まあそれは置いておくとして、知識ゼロの人にテスト界隈説明しようとするとこうなるのかとか、テスト設計者はこういうこと考えてるのかという点では面白かった。 なぜソフトウェアテストの本なんか読んだかというと、普段つくっているライブラリを、もっとテストしなくていい形で抽象化したかったからというのが理由の一つにある。より良いテストを設計しようとすれば、自然とテストフレンドリーなライブラリが出来るだろうという仮定のもとで読んだ。autodoc みたいにメタテストツールみたいなものを作る上でも考えた
本記事はGo Advent Calendar 2014の18日目の記事です. Go言語は,クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い.自分もGo言語でいくつかのコマンドラインツールを作成してきた.例えば,GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている. コマンドラインツールをつくるときもテストは重要である.Go言語では標準テストパッケージだけで十分なテストを書くことができる.しかし,コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する.そのテスト,例えばある引数を受けたらこの出力を返し,この終了ステータスで終了するといったテストは,ちゃんとした手法が確立されているわけではなく,迷うことが多い(少なくとも自分は結構悩んだ). 本記事では,いくつかのOSSツール(得に
DevLove関西に行ったので、「課題をテストで解決する」という発表をしてきました。 内容はスライドに書いてあるとおりです。以下のことを特に話したくて、今回の発表をしました。 何度も起こる課題があったときに人が気をつけようとしない 最悪のケースでは根本原因を知ろうとせず、間違えた人を怒ることで解決しようとしてしまう 何度も起こる課題なら、機械に自動的にやらせる その例として今回はテストでやりましょうという話をした あとテストいろいろあって始め方がわからないという時は、こういう課題をテストにするというところから始めるとやりやすいかもしれない 参考 この資料作るにあたってひたすらブログ書いたので参考にどうぞ 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->b
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
Contents unittest を効果的に使うための覚書 目的 ルール: テスト対象のモジュール(module-under-test)をテストモジュールに直接importしない ガイドライン: モジュールスコープでの依存を最小限にする ルール: 各テストメソッドでは、1つの事実だけを確認する ルール: テストメソッドは内容を表すようにしよう ガイドライン: setupはヘルパーメソッドで提供しよう。テストケースのselfで共有するのはやめよう。 ガイドライン: フィクスチャは可能な限り簡潔に ガイドライン: フックやレジストリなどの利用は注意深く ガイドライン: 依存関係を明確にするためにモックを利用する ルール: テストモジュール間でテキストを共有しない まとめ https://twitter.com/tokibito/status/412074246026698753 ということで
© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会(ASTER) 理事 JaSST東京実行委員(2003年~) 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員(2006~) テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長(2011年~) Wモデル研究会 主査(2011年7月~) 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員(20
DjangoでAbstractなモデルの単体テストってどう書くんだろうなって思って調べたときのメモ。 継承した先のモデルをテストすればいいとかあるかもしれないけど、抽象モデルなので実装を持つ事ができる。その実装を独立してテストしたいなぁと思った。 簡単な例を書く。こんな論理削除用の抽象モデルがあったとする。 class BaseModel(models.Model): del_flg = models.BooleanField(u'削除フラグ', default=False) def remove(self): self.del_flg = True self.save() def unremove(self): self.del_flg = False self.save() class Meta(models.Model): abstract = True この場合、remove, u
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
DjangoのプロジェクトをJenkinsでビルドする場合、django-jenkinsを使うと便利。 PyPIからdjango-jenkinsをインストールできる。 $ pip install django-jenkins jenkins用のsettingsファイルを用意する Djangoのプロジェクトにjenkins用のsettingsファイルを追加して使う。 myproject/settings_jenkins.py 設定例。 # coding: utf-8 from myproject.settings import * INSTALLED_APPS += ( 'django_jenkins', ) JENKINS_TASKS = ( 'django_jenkins.tasks.django_tests', ) PROJECT_APPS = ( 'guestbook', ) この例
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
2012-12-26 Javaプログラマ必読の実践的テスト指南書『JUnit実践入門』レビュー 渡辺修司さん著『JUnit実践入門』が発売されてからかなり経ってしまいましたが、実はこの本、すこしだけレビューにも参加させてもらいました。私は結局少ししかご協力できなかったのですが、それでも献本頂きました。レビュー段階からこれはいい本になると思って、ぜひレビューを書こうと思ってましたが、遅れに遅れ、今になってしまいました。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本(ソフトカバー)購入: 12人 クリック: 238回この商品を含むブログ (19件) を見る この本、私は読者としてプログラマとしてかなり助けてもらってますので、基本的に褒めるところしかない
You recently received an email asking you to confirm your contact details. Because you didn’t confirm within 15 days, your domain was deactivated. Final reminder: we’re holding onto your domain for an additional 7 days. After that, you won’t be able to reactivate it. To keep this domain, reactivate it as soon as possible.
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く