タグ

ソフトウェアテストに関するs_hiiragiのブックマーク (9)

  • assertEqualsやassert_equalの引数はなぜ expected, actual の順なのか、調べてみた - Qiita

    そこで、expected, actualの順で引数が並ぶのには何か理由があるのか、ちょっと調べてみました。 調査方法 "unit test assert equal argument order why" みたいなキーワードでググってみました。検索の上位に毎度お馴染みのStack Overflowのリンクが上がってきたので、いくつか回答を覗いてみました。 Kent Beck氏は何と言っているか? JavaのJUnitRubyのtest-unit/minitestなど、いわゆるxUnit系のテスティングフレームワークはKent Beck氏が始祖の一人であると言われています。 1997年に、Smalltalk のためのユニットテストのフレームワークであるSUnitをもとにして、エーリヒ・ガンマと、SUnitの開発者のケント・ベックが中心となって開発された。 JUnit - Wikipedia

    assertEqualsやassert_equalの引数はなぜ expected, actual の順なのか、調べてみた - Qiita
  • 20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog

    こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに番リリースしました。 「それってテストいるんですか?」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi

    20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
  • privateメソッドをテストしたい - 日々常々

    と思うのは、とてもいいこと。 前置き もし行いたいテストが外的振る舞いを示すものであれば(少なくともテストにより観測できる見通しがなければ「テストしたい」とは思わないだろうから、何かしら外から観測可能なものではある可能性は高い)、それがprivateに閉じていていいものではないと言う気づきのきっかけになる。 と言うのは教科書的回答だけど、外には見せたくないけれど複雑なロジックを包含していて、入念かつ局所的にテストしたいと思うこともある。 この動機はすごく自然。きっとそこはテストしなかったらバグってるし。テストしてもバグが見つからないと言うのもよくあるんだけど。 この手のがどうあるのがいいのかはチーム体制も含めたプロダクトによると思っている。 綺麗な考え方は、独立したコンポーネントとして関心ごとや複雑性を閉じ込め、テストしたいと思った内容にもっと高い格を与える。「格」なんて表現は他で使ったこ

    privateメソッドをテストしたい - 日々常々
  • Google、ファジング「OSS-Fuzz」でJavaをサポート | OSDN Magazine

    Google(米Alphabet傘下)は3月10日、オープンソースソフトウェア向け継続的ファジングサービス「OSS-Fuzz」で、Java、およびKotlinScala、ClojureなどのJava仮想マシン(JVM)言語に対しても対象を拡大したことを発表した。 OSS-FuzzはGoogleが2016年に発表したファジングサービス。オープンソースソフトウェアに対して、意図的に例外を発生させて不具合を見つけ出すテスト手法であるファジング機能を利用できる。 Java、JVMベースの言語への拡大にあたり、GoogleドイツCode Intelligenceと協力している。Code Intelligenceは2月にJVM向けのファジングエンジンとしてJazzerをオープンソースにしており、Googleはこれを統合した。JazzerはLLVMプロジェクトのファジングエンジンlibFuzzerを

    Google、ファジング「OSS-Fuzz」でJavaをサポート | OSDN Magazine
  • 複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO

    ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか?という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は当に有効なのか?組み合わせテスト技法と上手に付き合う方法 | DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか?条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I

    複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO
  • AlexaでE2Eテストを書けるようにした話 - クックパッド開発者ブログ

    研究開発部の伊尾木です。 研究開発部では、Alexaのスキルを公開しています(Google Assistantも公開していますよ!)。 今回はAlexaスキルのテストを便利にするKuchimaneというツールを公開したので紹介したいと思います。 E2Eテストが難しい 音声UIの開発はまだまだ新しい分野で知見やツールがそろっているわけではありません。 特に E2E (End To End) テスト、RSpecでいうところの Feature spec に相当するようなテストを行うことがとても困難でした。 AlexaでのE2Eテスト 以下のような一連の会話があったとします。 あなた「クックパッドを開いて」 Alexaクックパッドへようこそ」 あなた「大根のレシピを教えて」 Alexa「大根ですね。サラダ、ナムル、スープのどのレシピがいいですか」 あなた「スープAlexa「大根のスープですね

    AlexaでE2Eテストを書けるようにした話 - クックパッド開発者ブログ
  • スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita

    あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。(私がテスト好きなのは否定しません) 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか?という記事で(私の記事をきっかけとして)テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ

    スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
  • テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita

    テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした: 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま

    テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
    s_hiiragi
    s_hiiragi 2017/12/01
    "どこにテストを書けば開発速度を上げられるのか判断するには、一定の経験が必要です。"
  • JaSSTソフトウェアテストシンポジウム

    JaSSTは、NPO法人ASTER (ソフトウェアテスト技術振興協会)が運営しています。詳細につきましては、こちらをご覧ください。 NPO ASTER のウェブサイトへ ※JaSSTの参加申込受付は、株式会社イベント・レンジャーズが実施しています。 2024/03/15 JaSST'24 Tokyo を終了いたしました。 2024/03/15 JaSST'24 Tokyo の参加お申込み受付を終了しました。 2024/03/12 JaSST'24Hokkaido の実践事例募集の受付を開始いたしました。 2024/03/12 JaSST'24Hokkaido の実行委員募集要項を掲載しました。 2024/03/12 JaSST'24 Hokkaido の開催要項を掲載しました。 2024/03/12 JaSST'24 Hokkaido を2024年8月23日(金)に開催いたします。 202

  • 1