Introduction Hello, I'm Arthur Guiot, I created DisplayJS not that long ago, and I figured out that I couldn't find an easy to setup testing framework. So, I wanted to create my own, and here it is. EyeJS is easy to setup, and has some unique features, such as the ability to test your project right in a browser, which make it adapted to real world test. Installation We recommend using node 8, but

Performance is an important criteria when choosing test-runner. Tests should pass as fast as possible to detect errors earlier, improve developer experience and reduce CI servers running time. In this story I will compare the most popular JavaScript test-runners on the same set of unit tests and find the winners. CandidatesI will not go deep into the specific features of test-runners. Each one has

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

freee Engineers Advent Calendar 2016 12月17日担当の @futoase です。 現在、E2Eテスト基盤構築の担当をしています。1 Capybara、SitePrism および Selenium に触れていく中で自分や弊社メンバーから得た知見について記載します。 4点の内容となります。 Capybara + SitePrism Selenium E2Eの目的 E2E基盤構築を担当してみて思ったこと Capybara + SitePrism 同僚の @kompiro が Capybara + SitePrism を使うことを提案、フレームワーク化を行ってくれたのでテストケース作成に利用しています。2 Selenium/Appium Advent Calendar 2016にてSitePrismを利用したPageObjectsパターンを使ったテスト作成につ

はじめに みなさん、日頃JavaScriptのテストはどのように行っていますか？ 昨今ではAngularJSやReactJSを始め、JavaScriptのフレームワークやライブラリを使用してのフロントエンドの開発が当たり前のようになってきております。 ではそのフロントエンド、JavaScriptのテストはどんなツールを使っていますか？ mochaやpower-assert、chai、Karma、Jasmine等を組み合わせて使用してテストしているでしょうか。 前置きが少し長くなりましたが、Facebookが開発したオールインワンな「Jest」というツールのReactでのHowto的な使い方から実際のテストでの使用例を交えて紹介したいと思います。 ちなみにこのJest、最近リリースされて話題になったパッケージ管理のYarnでも使われています。 対象バージョン Jest:22.0.4 Reac

最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出

新しい職場で提案したら歓迎されたので投稿しておく。 テストコード開発方針 漫然とテストコードを書いていると、以下のような問題が発生することがある。 テストに時間がかかりすぎ、待ち時間が発生したり、テスト結果を見なくなったりする テストコードの開発とレビューに時間をかけたが、そのコストに見合う利益を得られない このような問題を避けるため、以下の方針を定める。 ビジネス上の価値に比例したテスト コードの価値をビジネスへの影響や回避方法の有無により以下のようにランク付けする。 メジャー サービスの主たる機能に影響する 再現条件が広い 回避方法がない／あっても自明でない マイナー サービスの副次的な機能に影響する 再現条件が限られる 回避方法がある トリビアル サービスには影響しない 違和感はあるが、不便を感じない 回避する必要がない 複数のランクに該当する場合、より多く該当するランクに分類する。

Recommended practices for testing apps using ReduxExamples of test configuration and setup Guiding Principles​The guiding principles for testing Redux logic closely follow that of React Testing Library: The more your tests resemble the way your software is used, the more confidence they can give you. - Kent C. Dodds Because most of the Redux code you write are functions, and many of them are pure,

START: ListView ✔ propsが正しく設定できる Finished in 0.017 secs / 0.008 secs SUMMARY: ✔ 1 test completed --------------|----------|----------|----------|----------|----------------| File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines | --------------|----------|----------|----------|----------|----------------| parts/ | 90.48 | 58.06 | 100 | 100 | | ListView.js | 90.48 | 58.06 | 100 | 100 | | -

この記事は，TDDに見切りをつけたある大学教授の経験と，Uncle Bobの反論を要約したものだ。 ソフトウェア工学の大学教授を退官したIan Simmerville氏には，“Software Engineering, 10th edition”を含む数冊の著書がある。同書の第８章はすべてソフトウェアテストに関する内容であり，特に8.2章ではTDDを取り上げている。それらの章で紹介された考え方を何度も引き合いに出しながら，Sommerville氏は先日の記事に，“TDDはソフトウェア工学の大きな進歩です。いくつかのクラスのシステムにおいては，それが有効であることが明らかです。”と述べて，次のような“TDDフレンドリ”なシステムの一覧を紹介している。 階層化アーキテクチャ 合意された成功基準を持ち，それに準拠したテストに基づいて構築されるシステム。 自身のコントロールを越えてシステムと対話す

Testing is a vital part of any development process. Whether a project’s authors are hoping for scalability, fewer bugs, or just code that stands the test of time, a solid test suite is essential. It’s all well and good writing tests, but how do you know that you’ve tested the code that matters? Did you cover the most important components? Did you test the sad path? The edge cases? What about the z

Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr

unassert - Encourage Design by Contract (DbC) by writing assertions in production code, and compiling them away from release. Takuto Wada 2015/11/07 @nodefest Tokkyo 2015Read less

お世話になります、フロントエンド担当をしている小原正大です。Webページの表示を監視して差異があった場合、どのページで表示の変化が起きているかを知ることが出来るプログラムを実装したのでそのことについて書こうと思います。 何につかったの？ 僕がフロントエンドを担当しているサービス『料理サプリ』で大規模なフロントエンドコードのリファクタリング行う際に表示テストを自動化するために作成しました。『料理サプリ』はPC・スマホ合わせて大体350-400ページの表示パターンが存在する比較的規模の大きいサイトです。全ページに影響を与えるような作業は大規模な回収となり、今回のリファクタリングでは表示テストの計画などの段取りが必要でした。従来の人手によるQAでは細かいバグを見過ごしたり時間がかかり効率が悪いので、可能な限り自動化しようと考え実装しました。 実装の概要 この監視のシステムは以下の２つ実装を組合わ

これまで VanillaJS / jQuery で頑張ってたプロジェクトに React 入れて、Reactは最高！などと言っていたのだけど、E2Eテストが落ちている事に気づいた。 落ちたテストで画面キャプチャしたりして調べた結果、Reactコンポーネントを描画するところで落ちていた。 どうやらPhantomJS1系で見られる現象のようだった。 e2e - CasperJS で Reactjs のサイトをテスト - Qiita E2EテストにはCasperJSを使っていた。 Casper の dependencies は "phantomjs": ">=1.8.2" となっている。 PhantomJS の謎な挙動にはユニットテストでも散々苦しめられていた。 既に polyfill 幾つか入れて対処していたのだけど、良い機会なので別の道を模索してみよう、という話になった。 頑張ってPhanto