E2Eフレームワークを触って、特徴を紹介する
![JavaScriptのE2Eフレームワークを触ってみる](https://cdn-ak-scissors.b.st-hatena.com/image/square/893cb785bceedb22bedb5547222ae8bb3af3d41c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff28142bd0b234aa3bcb7de8bb1b56916%2Fslide_0.jpg%3F9297581)
テスト書くのが当たり前、だけど・・・和田:次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
みなさんはこんなふうにRailsアプリケーションを作ったことはありませんか?たとえば、ブラウザをポチポチとクリックするだけでテストを終わらせて「たぶん大丈夫」と思い込んだり、「とにかく全部うまくいきますように」とただ祈るだけだったり……。 心配しないでください。それは誰もが通る道です。アプリケーションのテストやテスト駆動開発はRails開発における重要なトピックですが、巷の参考書を見ると適当な説明で済ませているものも多かったりします。本書「Everyday Rails - RSpecによるRailsテスト入門」では、どのようにして私がそうしたテクニックを身につけたのか、そして、どのようにしてコードの信頼性を上げ、ブラウザ上で延々とテストしなくて済むようにしたきたのかをみなさんに説明します。 対応バージョンについて2024年1月のアップデートで、本書のコンテンツをRails 7.1とRSpe
こんにちは、@nazomikanです。 この記事はLIFULL Advent Calender2017 その2の3日目の記事です。 昨年のAdvent Calenderでselenium-webdriver(node)のapi翻訳記事を書きましたが、その当時対象としてた2系から現在はメジャーバージョンアップを挟んで色々と現状が変わってきてるのでその辺の話をします。 ローカルモードでのテスト時にselenium standaloneサーバが不要に v2.43のチェンジセットでFireFoxのネイティブサポートが追加されて、remoteでの実行時を除いてサポート対象の全てのブラウザがstandaloneサーバなしで実行できるようになりました。 (chrome/phantomjsのネイティブサポートは2.34) ※のちにphantomjsとoperaのサポートは切られる ※この当時サポート対象で
Speee エンジニア組織推進室の服部 (yhatt) です。 みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpec、Capybara、 Poltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。 そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。 ヘッドレス Chrome ことはじめ | Web | Google Developers [A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く