この記事は、はてなエンジニアアドベントカレンダー2016の5日目の記事です。 こんにちは、はてなでアプリケーションエンジニアをしている id:shiba_yu36 です。先日、buildersconにおいて、現在所属しているプロジェクトでJavaScriptのユニットテストを導入した知見について、「一から始めるJavaScriptユニットテスト」というタイトルで発表しました。 speakerdeck.com この発表は、実際にJavaScriptのユニットテスト環境を作ってみると非常にハードルが高いと感じたので、そのハードルを少しでも下げられればという思いで、非常にシンプルな例で一から環境を作る例を紹介しました。アジェンダは次のとおりでした。 カクヨムのJS環境 JSのテストツールを整理する 通常の関数のユニットテスト DOM操作する機能のユニットテスト カクヨムのJS環境や、JSのテスト
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするかという記事がバズりました。みんなテストについて思うところがあるようだ。テストを書くべきか否かは机上の空論になりがちで不毛なので、どうやってテストを書くか、テストの書き方、について、種を巻いた私が書いておく。 もっと詳しい方からのお話お待ちしています。 書くこと テストの書きやすくするためのいろいろ（箇条書き） 書かないこと テストの基本 テストファースト 実装ありきでテストを書くのではなく、テストありきで実装を変える。 はっきり言って、テストを考慮せずに実装されたコードは、書き直さずにはテストできない。 そういう点で、テストなしで実装する選択肢は不可逆なので、初期実装では特に注意が必要。 クリーンアーキテクチャ(DDD) クリーンアーキテクチャの考え方はテストファーストを語る上で重要。私個人としてはまだクリーンアーキテクチャ
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか というという記事がバズって以降テストの記事ばかり投稿しています。この際だからテストに関するもやもやを吐き出しておきます。 上記記事にてToDoとして、 すでに生み出されて動いているレガシーコードにどう立ち向かうか と書きました。 一回レガシーコードと戦って勝利一歩手前まで行った経験があるのでその経験をまとめます。 どんなコードだったか 規模は小さめ ユニットテストなし 自動テストなし テストはデプロイしないと不可 前任者（作成者）いない UIなし やりたいこと テストがあれば一時間で終わる程度の変更を加える 格言 レガシーコードの改変について有名な格言があり、 レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。 「レガシーコード
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「
Webエンジニアの森脇です。LCLでは、以前より「Capybara + PhantomJS」でE2Eテストを行っていましたが、「Puppeteer + Headless Chrome」へ変更しました。 元々は、軽くPuppeteerを触ってみるだけのつもりでしたが、できが良く本格的にE2Eテストへ導入することにしました。 本記事では、変更の経緯や、PuppeteerでE2Eテストを実装する上でのTIPSを紹介します。なお、Capybara + PhantomJSを利用したE2Eテストは、以下の記事でご紹介しております。 techblog.lclco.com 変更の経緯 PhantomJSは古めのWebkitをベースにしているため、一部のCSSがうまく適用されず、Headless Chromeへ移行を以前より考えていました。そんな中、PhantomJSの開発が終了したこともあり、移行すること
はじめに 既存のコードに対するテストを書く時など、テストを書くこと自体の工数を削減できないかという観点にて、スナップショットテストと言うものを試しました。PHPUnitにもスナップショットテストのライブラリが提供されているのでその使い方についてまとめます。 そもそもスナップショットテストとは もともとは、Facebook製のJSテストフレームワークJestの機能として提供されているものです。 また、スナップショットテストのすゝめという@kenttさんのスナップショットテストについての記事が概要に知るにはとても参考になるのでおすすめです。 上記の記事を引用させていただくと、概要はこんな感じです。 スナップショットテスト 最初のテスト実行時にテストケースのアウトプットが保存（スナップショット）される スナップショットを目視で確認して期待通りならOK 2回目以降はアウトプットとスナップショットを
先日の話ですが、5 月下旬に開催された de:code 2018 に、若手エースコンサルタントの原田さんと一緒に登壇させていただきました。私事の関係で突発で穴を開けるリスクがあり、今回は登壇を見送ろうかと思っていたのですが、原田さんに協力いただけるとのことになったので、初めて共同登壇という形にさせていただきました。二人で登壇するといろいろ気付きもあり、私自身、非常によい経験になりました。（改めて原田さん、無茶ぶりに協力していただいてありがとうございました。m(_ _)m） さて de:code 2018 では IT Modernization の重要性について説明し、そこから手動テスト（打鍵テスト）の効率化について取り上げて解説を行いました。日本の多くの SIer では未だ Excel を使った打鍵テストが行われまくっていますが、この部分は VSTS/TFS の Test Manager
題目の通りなのですが、PHPUnitで複数のアサーションを実行して最後に失敗があったか確認する方法をメモしておきます。 本来(なるべく)なら1テスト1アサーションがいいのでしょうけど、とりあえず簡単なアサーションをざぁーーーっと流して最後に失敗したものだけを確認したいこともあるのではないのでしょうか。 そんな要求を満たすには以下の方法もあるのではないかという話です。 ※すいません、これ以外やったことありませｎ 方法 以下の例外をキャッチする。 \PHPUnit_Framework_ExpectationFailedException はい、これだけです。 PHPUnitでテストに失敗した時、内部では上記の例外をキャッチしてゴニョゴニョしているようです。(多分) なので、一旦上記の例外を先にキャッチしてしまいます。 サンプル 簡単なサンプルは以下の通りです。 ※エラーメッセージはjsonにし
Less Code, Less Maintenance, More Acceptance Testing Gauge is a free and open source test automation framework that takes the pain out of acceptance testing Gauge + Taiko = Reliable browser automation for your JavaScript tests! Create readable and maintainable tests Gauge tests are in Markdown which makes writing and maintaining tests easier. Reuse specifications and robust refactoring to reduce d
Quipper で Web Engineer 兼 Engineering Manager を務める @ohbarye です。スタディサプリの開発、その中でも特に合格特訓コースや決済周りの機能開発・保守が主な業務です。 弊社が開発するプロダクト「スタディサプリ」ではA/Bテストを用いたプロダクトの改善を行っています。Quipper の行動指針の一つに "Fact based" という言葉が含まれており、憶測や独断ではなく計測されたデータや事実に基づいて意思決定することが強く推奨されているためです。 このたびスタディサプリにおいて負債と考えられていた機能を「消してよいかどうか」、A/Bテストを通して判断しました。その際に用いた手法や結果、そこから見えたこと、考えたことをご紹介します。 プロダクトの負債とは プロダクトチームにとって負債と考えられていたのは「キャリア決済」という決済手段でした。そ
<?php class SampleClass { public function __construct() { exit; } public function hoge() { return TRUE; } } <?php require_once 'SampleClass.php'; class SampleClassTest extends PHPUnit_Framework_TestCase { public function testHogeReturnTrue() { $this->class = new SampleClass(); $this->assertTrue($this->class->hoge()); } }
class StubTest extends PHPUnit_Framework_TestCase { public function testReturnValueMapStub() { $mock = $this->getMockBuilder('SomeClass') ->getMock(); // 値を返すためのマップ // 配列の先頭から第一引数、第二、、、として、最後にダミーの返却値 // この場合は引数が3つ $map = array( array('a', 'b', 'c', 'd'), array('e', 'f', 'g', 'h'), ); $mock ->method('doSomething') ->will($this->returnValueMap($map)); // $mock->doSomething() は、渡した引数に応じて異なる値を返します $th
スナップショット機能で大きなオブジェクトを容易に追跡できるテストを作成できます。スナップショットはテストと一緒に、あるいはインラインに埋め込んだ状態で表示できます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unit test Http Services on Angular 2