外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker DeckOct 31, 2018 at AWS Dev Day Tokyo 2018 #AWSDevDay #AWSTDD
Jestなどを使わずにスナップショットテストを書く
次のようなテストコードを書きます。(これはMochaを使っていますが大体どんなテストフレームワークでも同じことが出来ます。) 次のスナップショットでは、transformというJSONを入力に受け取り、JSONを出力する関数をテストしています。 snapshot-test.js: const fs = require("fs"); const path = require("path"); const assert = require("assert"); const fixturesDir = path.join(__dirname, "snapshots"); // transform function const transform = require("../transform"); describe("Snapshot testing", () => { fs.readdirSy
Assert(js) 2019: a conference for JS developers focused on testing
The JS Testing ConferenceAssert(js) is a conference for JavaScript developers focused on testing. From TDD techniques and process to JS testing tools and frameworks, both UI and Node.js. Watch the talks As developers we know that automated testing helps us write better code, build more reliable products, and keep our development velocity consistently high. As JavaScript developers we also know tha
一休.comのJavaScriptユニットテスト環境 - 一休.com Developers Blog
この記事は一休.com Advent Calenrad 2017の2日目です。 宿泊事業本部フロントエンドエンジニアの宇都宮です。 一休.comの宿泊予約サービス（以下、一休）では、以下のようなスタックでWebフロントエンドの開発を行っています。 言語：ES 2017 ライブラリ・フレームワーク：古いところはjQuery、新しいところはVue.js ビルドパイプライン：Webpack + Babel 一休では、主要導線のE2Eテストは整備されています*1。一方、フロントエンド(JavaScript)のユニットテストは発展途上といったところです。 本記事では、一休のJSユニットテスト環境の変遷と現状について紹介します。 AVA 2017年4月の時点で、一休のJSユニットテスト環境は以下のような状況でした。 テスティングフレームワーク：AVA Babelでビルドされているコード：1,000行程
テストや開発環境における自動化に関して議論したICST2017 unofficial meetup - クックパッド開発者ブログ
技術部品質向上グループの松尾(@Kazu_cocoa)です。 2017年3月13日〜2017年3月17日の間に、東京にてICST2017という国際学会が開かれました。 その学会に基調講演としてGoogleの方などが来日しました。そのさい、非公式ながらミートアップを開いたのでその時の学びを共有したいと思います。 ICST2017とは ICST2017とは、2017年に開催された第10回 IEEE International Conference on Software Testing, Verification and Validationの略です。Webサイトはこちら。 そこではソフトウェアテストや開発環境、品質に関する研究や事例が発表され、議論されました。 今年は10周年である上に、この会が始まって以来、初めて日本で開催されたようです。 学会と聞くと学術的すぎると思うかもしれませんが、比
オープンソースの開発現場では限られたリソースで品質管理をどうしているのか。Twitter4J、GitBucket、Asakusa Framework、power-assertの作者が討論（前編）
和田氏 このセッションは、OSSにおける品質管理やテストなどをどう考え、運営しているのか、という内容でパネルディスカッションをさせていただきます。まずは登壇者がどんな方か、自己紹介してもらおうと思います。 竹添氏 ビズリーチの竹添と申します。転職サービスの会社なのですが、今日は個人で「GitBucket」という、GitHubのような機能を提供するWebアプリケーションを作っているので、その立場で参加させていただきます。 もともと僕はSIerにいて、そのときはGitHubのような外部のサービスを使えなくて、それで社内でもGitHubのようなサービスが使えたらいいなと思ってGitBucketをはじめました。 なのでGitBucketはGitHubを参考に開発を始めたのですが、同じようなニーズを持ったお客さんが国内にも、海外にも多くいるので開発を続けています。 川口氏 ノーチラス・テクノロジーズ
xUTPの著者から教えてもらった「テストのクラフトマンシップ」 - PoohSunny's blog
はじめに これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。 謝辞と注意点 この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros! 上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。 Unit Test Craftma
PICTでテストケースの組み合わせ爆発にさよならを - エンジニアをリングする
Goodpatch Advent Calendar 2016 13日目の記事です！ わたしはGoodpatchでProttというプロトタイピングツールのWebフロントエンドの開発を担当しています。 Prottでは、プロトタイプの再生に関する修正をしたあとは必ず全動作を網羅したテスト用プロジェクトでの動作確認を行っています。 ただ、すべての環境や条件を揃えた上でのテストにはなかなかの工数がかかってしまっていました。 この記事では、オールペア法という手法とPICTというCLIツールを使用してテスト工数を半分以下に削減した方法を紹介します。 単純に全組み合わせ 推奨環境としているOSやブラウザと3種類の再生モードを組み合わせると、テストすべき組み合わせは全部で20パターンになります。 （プレビューモードとプレゼンテーションモードは対PC、スタンドアロンモードは対モバイルのモードです。） - Ma
テスト計画の立て方 - Qiita
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
UnitTestでのprivateメソッドとの向き合い方 - ジムには乗りたい
privateメソッドのUnitTestについて、下記のような扱いがあると思う。 スコープを（例えばprotectedに）拡張する 直接間接を問わず、リフレクションなどを活用してテストする これらに対して、ずっと何か違和感を覚えていた。 実践JUnitでちょっと触れられている箇所があって、自分なりの読み解きで何となく向き合い方が腹落ちしたので書いておく。 UnitTestはメソッドのテストではなく、そのふるまいのテストにより重きが置かれるべき privateメソッドは実装の内部詳細であり、その変更はふるまいに影響をあたえるべきではない 上記の前提を考えると、基本的にはpublicスコープに対してのテストで十分になりえるはず。 そのクラスのふるまいであるなら少なくともパッケージ以上にスコープが（テストのためではなく）拡張されることに違和感はない。 そうでないならば別のクラスに切り出すようなふ
Unit Testing/1.0 - CommonJS Spec Wiki
STATUS: APPROVED BY DISCUSSION PARTICIPANTS Pardicipants Tom Robinson, Ash Berlin, George Moschovitis, Chris Zumbrunn, Hannes Wallnöfer, Kris Kowal, Kevin Dangoor, Ates Goral, and Davey Waterson (Discussion) Implementations [[Implementations/Flusspferd|]], [[Implementations/Narwhal|]] (0.2), [[Implementations/SproutCore|]], [[Implementations/node.js|]], [[Implementations/TeaJS|]], [[Implementation
Unit Testing - CommonJS Spec Wiki
STATUS: 1.0 RATIFIED, AMENDMENT PROPOSALS PENDING Unit testing Automated tests are an important part of software development today. Providing a standard test library will help encourage more people to write more tests. Additionally, the API specification will likely be written in the form of tests, so this component will be needed by the CommonJS project itself. Testing involves both an API for ea
The Art of Unit Testing
This expanded edition teaches mocks, stubs and dependency injection in functional, modular and object oriented style. The Art of Unit Testing, 3rd Editionwith Examples in JavaScriptThe Art of Unit Testing, Third Edition updates an international bestseller to reflect modern development tools and practices. You'll explore test patterns and organization, working with legacy code, and even "untestable
インテグレーションテストを書き始めた話 | Tokyo Otaku Mode Blog
こんにちは。Tokyo Otaku Mode (以下TOM) エンジニアのシンバです。今期のアニメは「甘々と稲妻」が一番の楽しみになっています。特に飯田小鳥を演じる早見沙織さんの声を聴くのが楽しみです。早見さんは9月に公開される映画「聲の形」のヒロイン役も担当されるそうで、そちらも非常に楽しみにしています。ヒロインのビジュアルがすごくかわいい。 さて、TOMは現在、ECサイトやニュースサイトなどを http://otakumode.com/ で展開しています。このシステムの開発にはNode.jsが使用されており、Mochaを使用してモデル層などのテストを書いています。ただ、このテストは関数一つ一つの入出力をチェックするために書かれているので、例えば複数の関数を組み合わせた際の結果や、色々処理した結果、ページ上に何が表示されるのかといったテストは書いていませんでした。 そこでインテグレーショ
enzyme+mocha+power-assertでReactコンポーネントのフルレンダリングテスト - wadackel.me
公開されている React コンポーネントのテストコードを見てみると、enzymeを使ってテストしているものを結構見かけます。enzyme はReact 公式でも押しているっぽいので、積極的に使っていきたいです。 Note: Airbnb has released a testing utility called Enzyme, which makes it easy to assert, manipulate, and traverse your React Components’ output. If you’re deciding on a unit testing library, it’s worth checking out: http://airbnb.io/enzyme/ 日本語の紹介記事では@syossan27さんの記事が参考になりました。 React のテストを Enz
RxJS(5.x)で行うテストファーストな機能開発｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
小飼です。 『The Next Great Burger』にハマっています。 RxJS、使っていますか？ 弊社では現在開発しているアプリケーションから、本格的にRxJSを導入して使い込んでいっています。 イベントを配列のように操作できるという高度な抽象化の恩恵で、非常にリーダブルかつ簡潔に機能実装が出来るところが非常に良いですね。 学び始めた当初はReactive Programming的な考え方で実装を発想するということができず、非常に難解なイメージを持っていましたが、 半年くらい置いて改めて使ってみたところ、非常に使いやすいライブラリであるというイメージにガラッと変わりました。 これはRPっぽい発想の転換ができたことと併せて、TypeScriptでRxJSを用いることで、静的型解析の恩恵を受ける事ができた事も大きいと思っています。 (少なくともAPIの多さは問題にならなくなりました)
Clean Coder Blog
At XP2016 I attended an open-space demonstration of mutation testing. In particular, an open source tool for the Java space named pitest. I came away pretty impressed. I had heard of mutation testing before. A decade and a half ago there was an open source tool named jester. Nothing much came of Jester back then. Perhaps we were too focussed upon TDD to think beyond it. After all, the very notion
xUTP Magazine - 第一回 xUnit Test Patterns の世界観
目的 はじめに テスティングパターンの一覧 パターンランゲージ 読み進めかた マーチン・ファウラーによる本書の構成の説明 私の読み方 原著者(Gerard Meszaros)による情報源 コミュニティによる情報源 さいごに この連載記事の目的は次のような感じです。 xUTP読書会で得られた知見を整理する xUnit Test Patterns に書かれている内容を分かりやすい形で広める 英語の壁も、難しさの壁も、読書会の有志による努力によって取り払われました。 軽い気持ちで、xUnit Test Patterns に挑戦してみましょう。 TDD にせよテストファーストにせよ、テストコードを書くのは近代的な開発では当然の行為です。 しかし、戦略の無いままに無数に書かれたテストコードは保守が難しかったり、 仕様変更によってプロダクトコードのみが修正されテストコードの修正は忘れられてしまうなど、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eric Ponto
Let's Make a Test Framework