🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
![Poku](https://cdn-ak-scissors.b.st-hatena.com/image/square/f1c5a05a86cc2a86fb3dba08ad6dbe50692a4b5d/height=288;version=1;width=512/https%3A%2F%2Fpoku.io%2Fimg%2Fsocial.png)
🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
Vue.jsのコンポーネント開発をTDDでやってみる ※ TDD (test-driven development): テスト駆動開発 ※ テスト駆動開発は文化です。チームの「状況」「納期」「スキルレベル」、その他いろんな要因が絡んできた結果、そのチームが導入するかどうか決めたらいいと思います。 ※ 例えがいいかはわかりませんが、私は「早起き」と「テスト」は同じようなものだと思っています。「早起き」は健康にいいよねって誰でも言うと思うけど、実際に万人がやっているかどうかは別じゃないですか。それと同じで「テストすること」も絶対いいことだと私は思っていますが、やるかどうかはチームの置かれている状況によって決まります。この記事は、その「テストを導入するかどうか」という意思決定の一助にでもなれればいいなと思います。 はじめに こんにちは。ぼくです。 今回はVue.jsでTODOアプリを作ってみよう
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発(TDD)の日本での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。最終回である今回は、power-assertの開発やテストに対する考え方などを聞いた。 (前回から続く) 自社製品を開発しようとワークフローエディターを自作して得たJavaScriptのスキルセットは、ぼくの大きな財産になりました。ワークフローエディターはかなり複雑なソフトウエアなので、テストコードなしでは開発は困難です。そこでJavaScriptのテストについてもいろいろ調べてみました。しかし、JavaScriptのテストの仕組みは当時はまだ全然発達しておらず、ほぼ手探り状態でした。 201
TDD という用語を使うとテストおじさんがやってきて、それはそうじゃないとか色々言い出すと思うんだけど、それが趣旨ではないので勘弁して欲しい。予防線ここまで。 Puppeteer でテスト Puppeteer が世間的にも個人的にもブームだ。ヘッドレス Chrome を操ってクローリングしたりスクリーンショットを撮ったり色々出来る。 github.com で、あれこれと遊んでいるうちにテストに使えるんじゃね?ということに気づいたので実践してみたら快適だったという話。ブラウザ操作してテストというのは昔から Selenium というのがあり、こちらはクロスブラウザで出来たりするんだけどまあ大掛かりでだるさを感じてしまう。メリットデメリットの比較はさておき、どうせならナウいやつを使ってみたい。よし使おう。 何をテストするか 普段から画面を見ながら開発しているので、どこに何が表示されているべきとい
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか? react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
この記事は、はてなエンジニアアドベントカレンダー2016の5日目の記事です。 こんにちは、はてなでアプリケーションエンジニアをしている id:shiba_yu36 です。先日、buildersconにおいて、現在所属しているプロジェクトでJavaScriptのユニットテストを導入した知見について、「一から始めるJavaScriptユニットテスト」というタイトルで発表しました。 speakerdeck.com この発表は、実際にJavaScriptのユニットテスト環境を作ってみると非常にハードルが高いと感じたので、そのハードルを少しでも下げられればという思いで、非常にシンプルな例で一から環境を作る例を紹介しました。アジェンダは次のとおりでした。 カクヨムのJS環境 JSのテストツールを整理する 通常の関数のユニットテスト DOM操作する機能のユニットテスト カクヨムのJS環境や、JSのテスト
TypeScriptでpower-assertを使ってテスト時に詳細情報を出そうとしたら, テスト実行そのものは問題ないのだが詳細情報が出なくて解決するまで小一時間かかってしまいました. せっかくなので注意点として共有しておきます. 2016/02/17 追記 DefinitelyTypedのpower-assert.d.ts側で対応されたため、本記事で書いていた注意点について気にする必要がなくなりました! 最新のDefinitelyTypedのpower-assert.d.tsを使って、
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
power-assert 5分ぐらいでわかるpower assert power-assert power assert assert(a === b); のような単純なアサーションのみ必要十分 Assert失敗時(テストが通らなかった時)に分かりやすい情報を表示 沢山のアサーションを使い分けしなくていいというメリット そもそも何故アサーションの種類が豊富なのか? 例) Chaiのexpect 33コもアサーションメソッドが存在 expect('foobar').to.contain('foo'); contain 含んでないから失敗した 失敗した時に何故失敗したのかを表示することが出来る どうやって動いてるの? power assert !== アサーションライブラリ コードを変換したりするのでツールに近いテストツール Work flow テストコードをpower-assert用に変換し
2014年1月17日、ベルサール新宿グランドにて開催された「エンジニアサポートCROSS 2014」の中の1セッション「実況解説つき!ペアプロでわかるJavaScriptテスト入門」をレポートします。 エンジニアサポートCROSS 2014とは 「複数の技術を身につけなければWebサービスは作れない=クロスしないと生きていけない」をテーマに、「エンジニアサポート新年会2012 CROSS」として第一回が2012年に開催された勉強会イベント、それがCROSSです。今年で3回目になります。 「実況解説つき!ペアプロでわかるJavaScriptテスト入門」 このセッションは「JavaScriptで書かれたよくあるコードをベースに、ペアプロでテストコードを足していく様子を解説者が説明する」という内容になります。 それでは、さっそくセッションの模様を見ていきましょう。 登壇者 本セッションの登壇者
This is a talk presented on 18 May 2012 at RedDotRubyConf, SG. ----- Your stylesheets are always in a mess. How can you fix this? The answer: TEST YOUR CSS! Then you will be able to refactor your CSS with confidence! Also presenting a Proof of Concept CSS Testing Framework, Cactus, which I have created - http://www.github.com/winston/cactus.
1. JS開発における TDDと自動テスト ツール利用の勘所 2012.12.06 株式会社マピオン 中村 浩士 12年12月5日水曜日 2. 自己紹介 中村 浩士 ( @kozy4324 ) 株式会社マピオン所属 主にWebアプリのフロントエンド開発 JavaScript, ActionScript 12年12月5日水曜日
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く