Rubyインタプリタの品質向上のために個人的にやっていること - クックパッド開発者ブログ
技術部の笹田です。Ruby 3.2 無事にリリースされて良かったよかった。 Rubyインタプリタは複雑なプログラムなので、当然のごとくバグが入ってきます。Rubyインタプリタ開発者は、これに対していろんな対策をしています。たとえば、テストを書いて、CI環境でチェックするとか、今となっては当然のことを、当然のごとくやっています（RubyCIやchkbuild、ruby/spec: The Ruby Spec Suite aka ruby/specなどの整備や、実行環境の日々のメンテナンスの成果です）。 これに追加して、個人的にテストをとにかくたくさん繰り返し行うマシン群を用意しています。テストの実行頻度をなるべくあげて、「時々しか発生しない」というバグを炙り出して、Rubyインタプリタの品質向上を目指すためです。本稿ではそんな、ちょっとだけ変わったテスト環境についての話をご紹介します。 この
事前条件も事後条件もテストも全部 assert!() でいいの？ まあ、いいんじゃないでしょうかという話
事前条件も事後条件もテストも全部 assert!() でいいの？ まあ、いいんじゃないでしょうかという話 Rustでは実行時表明とテスト表明の双方を同じ仕組み (panic機構) を用いて行います。 Rustを書くにあたって、この部分に違和感を覚えた人もいるのではないかと思います (多数派ではないと思いますが)。本稿ではこの違和感について分析し、Rustではそれで問題ないと確認することを目指します。 ※割とフワッとした話に終始します Resultとpanic Rustではエラー処理の方法としてResultとpanicの2種類の方法を提供しています。これは大まかに以下のように使い分けられます。 プログラムが想定しなければいけないエラー (ユーザーが誤った入力を与えた場合や入出力エラーなど) はResultを使う。 プログラムが想定外の状態に陥った場合 (意図しない配列の境界外参照など) はp
Prustiを使ってRustでプログラム検証をしよう
導入に際し、ドキュメントに書いてないこととか色々あってつらかったため、軽くメモ代わりに投稿しておきます。 また、Prusti を使う最も簡単な方法は VSCode の拡張である Prusti-Assistant を使うことですが、Vimの使用を見越しコマンドだけで使えるようにアレコレ設定しました。 Prusti の紹介 プログラミングにおいて、関数に対してプログラマが明示的に制約を課すことはよくあります。 例えば、次のような単純な関数 max を考えます。 fn max(x: i32, y: i32) -> i32 { let result = if x > y { x } else { y }; result } さて、この関数は次のような性質を持つことが期待されます。 resultはx以上かつy以上 resultはxまたはy そういった情報は多くの場合ライブラリのドキュメントなどに書い
［速報］AWS、クラウド障害をわざと起こす「AWS Fault Injection Simulator」発表。カオスエンジニアリングをマネージドサービスで実現。AWS re:Invent 2020
Amazon Web Services（AWS）は、開催中のオンラインイベント「AWS re:Invent 2020」で、アプリケーションに対してクラウド障害のシミュレーションを行える新サービス「AWS Fault Injection Simulator」を発表しました。 クラウド上で稼働するアプリケーションの耐障害性などを高めるために実際にクラウド障害をわざと発生させて問題点をあぶりだす手法は、「Chaos Enginieering（カオスエンジニアリング）」と呼ばれています。 Netflixが2012年にカオスエンジニアリングのためのツール「Chaos Monkey」を公開したことで広く知られるようになりました。 参考：サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 今回発表された「AWS Faul
ソフトウェアテストの実行を機械学習で効率化する。Jenkins作者の川口氏が立ち上げた「Launchable」で実現しようとしていることとは（後編）
ソフトウェアテストの実行を機械学習で効率化する。Jenkins作者の川口氏が立ち上げた「Launchable」で実現しようとしていることとは（後編） Jenkinsの作者として知られる川口耕介氏は、昨年米国で新会社「Launchable」を立ち上げ、日本にもその100％子会社であるLaunchable Japanを近日中に立ち上げ予定です。 Jenkinsの登場がテストやビルドの自動化を促進し、ソフトウェアの開発生産性を向上させたことは明らかでしょう。川口氏によると、Launchableは機械学習などの技術を用いてそれをさらに前進させるものだとしています。 インタビューを行った5月末の時点で、同社は米国に6人、日本に4人と10人ほどの体制で製品開発を進めています。 果たしてLaunchableはどのようなビジョンで何を実現しようとしているのか、同社共同創業者兼共同CEOの川口氏と、Laun
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
機械学習でテスト時間を10分の1に、Jenkins生みの親・川口氏の新会社が始動
継続的インテグレーション（CI）を実現するオープンソースソフトウエア（OSS）「Jenkins」の生みの親として知られる川口耕介氏らが米国で設立したスタートアップのローンチャブル（Launchable）が、このほど日本で活動を始めた。同社は2020年1月に設立した。 1万個のテストケースを100ケースに圧縮 元クックパッドCTO室長の庄司嘉織氏がプリンシパル・ソフトウエア・エンジニアとして参画するほか、3人のエンジニアが2020年5月までに国内でチームに加わり、ソフトウエアのテスト工程を機械学習で効率化する技術を開発する。日米拠点が連携し、世界に通用するITサービスの立ち上げに挑む。 「1万個のテストケースを、バグの発見につながる100のケースに圧縮することで、テスト工程の時間を短縮できる」。ローンチャブルの川口共同CEO（最高経営責任者）はサービスの意義をこう語る。金融システムから組み込
Launchableからこんにちは - 川口耕介のブログ
2020年は僕にとって転機の年になります。というのも、今月末でJenkinsプロジェクトからは一歩退き、CloudBeesでは顧問に退き、そして新しい会社Launchableを始めるからです。 思えばJenkinsは色々な人のおかげで言い出しっぺの僕の予想を遥かに超えた大掛かりなプロジェクトに成長しました。本当に子供の成長を見るような思いです。だから、いつからか、僕としては後をどうやって引き継ぐかを考えるようになりました。今日、コミュニティとCloudBeesのおかげで、新しいボードメンバー達であったりJenkins Xであったり、コミュニティに新しいリーダーが育っています。なので、安心して彼らに今後を託す事が出来ます。実際の所、2019年中から徐々にプロジェクトから手を引き始めて色々な事を色々な人に任せてきたので、この発表で何かが突然大きく変わるということはありません。引き続きJenki
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
現在時刻が関わるコードを関数型で書いてテスタビリティを見てみた - Qiita
最近、現在時刻が関わるプログラムを題材に、高テスタビリティなプログラミング作法を解説した素晴らしい記事が復刻されて、感想などがTLに流れてきたので、自分もそのお題を関数型プログラミングで解いてみた記事。 はじめに 最近、こんな引用ツイートをした。 関数型界隈だと、参照透過な部分とそうでない部分（現在時刻, 乱数, etc.）を分離しといて使うところで合成する作法が尊重されてて、simplicity と composability の結果として、テスタビリティや柔軟性が高くなる（低くならない）ということがよく謳われている。あとで自分もFPでお題解いてみよう。 https://t.co/00TwqXmtC7 — yasuabe (@yasuabe2613) September 30, 2019 元記事は、t-wadaさんの『現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ 』で、めち
【社内勉強会】和田卓人氏によるレガシーコード改善ワークショップを開催しました
サーバーサイドエンジニアサブマネージャーの崔です。 少し前のことになりますが、テスト駆動開発（TDD）のエバンジェリストである和田卓人（@t-wada）さんを講師としてお招きし、1日かけてレガシーコード改善ワークショップを開催しました。 和田さんには以前にも、社内でテスト文化への理解を広めたいという意図もあり講演をお願いし、非常に好評だったため、今回はより実践的なワークショップを開催することにしました。 私たちが長期にわたって運用を続けるゲームタイトルは、機能追加や改善を繰り返し、システムが大規模かつ複雑になってしまいます。開発のスピードとプログラム品質の両立に影響するため、これらを改善する取り組みのひとつとして、テストを活用して開発効率を上げたいと考えました。 そして、今回はより実践的なワークショップにするために、Cygamesで実際に運用しているゲームタイトルのソースコードを利用しまし
QAエンジニアってどんな仕事？～ゲーム開発におけるテストの世界～ - SEGA TECH Blog
はじめまして。 セガゲームス「龍が如くスタジオ」専属QAエンジニアの阪上と申します。 今回は、QAエンジニアという職種の紹介とゲーム開発におけるテストの話を、「龍が如くスタジオ」での開発の歴史を振り返りながらご紹介したいと思います。 目次 目次 ゲームのテストって何をするの？ QAエンジニアの仕事内容 (2009年～) 自動プレイテスト (2013年～) QAエンジニアの誕生と加速するテスト環境の自動化 (2015年～) テストの結果分析 (2018年～) テストピラミッドの考察とQAエンジニアリングの未来 まとめ 参考資料 ゲームのテストって何をするの？ 本題に入る前に、QAエンジニアのQAとは何なのかを説明しておこうと思います。QAは 「Quality Assurance」の略で、日本語では品質保証という意味です。ゲーム開発においては、ゲームが正しく動作しているか、バグがないか、ゲーム
「WebDriver」がW3Cの勧告に到達。Webブラウザのテスト自動化などを実現
Web技術の標準を策定するWorld Wide Web Consortium（W3C）のBrowser Testing and Toolsワーキンググループは、「WebDriver」が6月5日付けで勧告に到達したことを発表しました。 WebDriverは、Webブラウザを外部から操作することを可能にし、Webアプリケーションのテストなどの自動化を実現する技術です。 主要なWebブラウザにはすでにこのWebDriverの機能が用意されています。Seleniumに代表されるWebブラウザ自動化ライブラリを利用することで、WebDriverを用いてWebアプリケーションのUIテストなどを自動化することが可能です。 SeleniumからW3Cへ もともとWebブラウザには外部から操作を行うAPIなどはなく、WebページやWebアプリケーションをWebブラウザで表示した際に画面が正常に表示されている
自分のコードを嫌いにならない、そのためにやるべきこと
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。最終回である今回は、power-assertの開発やテストに対する考え方などを聞いた。 （前回から続く） 自社製品を開発しようとワークフローエディターを自作して得たJavaScriptのスキルセットは、ぼくの大きな財産になりました。ワークフローエディターはかなり複雑なソフトウエアなので、テストコードなしでは開発は困難です。そこでJavaScriptのテストについてもいろいろ調べてみました。しかし、JavaScriptのテストの仕組みは当時はまだ全然発達しておらず、ほぼ手探り状態でした。 201
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
コスパで学ぶ自動テストのはじめ方 - 若くない何かの悩み
Qiita 週間ランキング1位を獲得しました Kuniwak です。ご愛顧ありがとうございます。 qiita.com さて、本題に移りたいと思います。 つい最近ですが、勤め先の別チームに向けて自動テストの導入を支援するための資料を作成しておりました。こちらを共有したいと思います。 speakerdeck.com 資料中にある「仕様化テストを推奨しない」という決断には賛否両論あるかと思います。仕様化テストを推奨しなかった理由は、仕様化テストにかかるコストは相当に高く、本当に余裕があるときでないと選べない選択肢だったからです。今回自動テストを導入しようとしているチームは、見るからに余裕のない状況だったので仕様化テストからやれとは言えませんでした。 もし、「自分だったらこうする」等のアドバイスがあれば、ぜひ参考にしたいと思います。コメントなどに書いていただけると嬉しいです。
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
『テスト駆動開発』を読んで - まめめも
テスト駆動開発posted with amazlet at 17.10.12Kent Beck オーム社 売り上げランキング: 563 Amazon.co.jpで詳細を見る オーム社さまから電子書籍を贈本いただきました。ありがとうございます。 本書はテスト駆動開発（TDD）の原典で、たいへん有名な本です。が、自分は食わず嫌いで読んだことがありませんでした。 というか、TDD 自体もちゃんと理解したことがありませんでした。なんだろう、なんか怖かった。 そんな自分が今回この本をいまさら読んでみたら、なるほどこれは確かにいい本でした。なんというか、語りたくなる感じ。ということでご紹介。 紹介 テストとプログラムを交互に書いていく開発方法 TDD を、例題を用いて実演していく本です。 TDD というと「プログラムより先にテストを書く」というところだけ強調されますが、正直それではよくわからないのでし
@t_wadaとケントベックのテスト駆動開発 - L'eclat des jours(2017-10-09)
_ @t_wadaとケントベックのテスト駆動開発 長らく絶版となっていたケントベックのテスト駆動開発（入門）が、オーム社から装いと訳者もあらたに再刊されて、しかも嬉しいことに、編集の森田さんから頂けたので早速紹介する。 くだくだしいことなどは後のほうで書くことにして（このページ群はおれにとってはその時考えたことなどを記す日記でもあるからだ）、まず本書の要点について書く。 原著は2003年、本書はそれの翻訳なので15年以上の歳月を経た準古典だ。何についての準古典かといえば、題名からわかるように開発についてで、なんの開発かと言えばプログラムだ。 一言で言えば、1人でプログラムを開発するときに、どのように開発へのモチベーションを維持しながら、開発そのものをゲーム化して楽しみながら（まあ、1人でプログラムを開発しようとした時点で、それはゲームなのだが、さらにルールをいくつか導入することでゲーム性を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptのE2Eフレームワークを触ってみる
