発見遅れたCOCOA不具合、厚労省「実機テストせず」：朝日新聞デジタル
情報技術（IT）を使って新型コロナの感染拡大を防ぐ「切り札」として導入された接触確認アプリ「COCOA」。利用者の約3割を占めるアンドロイド版が昨年9月末から4カ月以上、機能していないことが分かった。なぜこのような事態になり、発見が遅れたのか。厚生労働省が3日夜に開いた記者説明の主なやり取りは以下の通り。 ――どのような不具合が起きたのか。 「昨年9月28日にCOCOAのバージョンアップをした。それ以降の1月までは基本的な動作テストしかしていなかった。そのなかではちゃんと動いていると業者が判断した。年明けに拡張してテストしたら動いていないと判明した」 「9月28日は、（iPhone〈アイフォーン〉向け基本ソフト）iOSで濃厚でない接触でも（通知が）来てしまうことの不具合を直した。その時に、時間、距離とかのパラメーターに変更を加えた。iOSはそのときうまくいったが、アンドロイドは濃厚接触があ
Dropbox での同期のテスト 確信を持って同期の中核コードを書き換えるまで
0 0 3 0 Dropbox の同期エンジンのコードを完全に書き換えるのは、困難な道のりでした（その目標と決断までの詳細については、以前の投稿をご覧ください）。コードの書き換えとは、運用中に膨大な数のユーザーのマシンで稼働している Dropbox を支えるエンジンを入れ替えることです。正しくコードを書き換えるには、テストの自動化に本腰を入れる必要がありました。私たちが策定したテスト戦略のおかげで、コードを書き換えている間、いつでも正しい方向に向かっていると確信が持てました。このおかげで現在も、短いリリース周期で新機能の開発と出荷を続けることができます。 ここでは、最初に新しい同期エンジン「Nucleus」の設計に反映したテスタビリティの検討事項と、テストしやすいアーキテクチャ上に構築したランダム化テスト システムの一部について説明していきます。 目次 テスタビリティ 1-1. プロトコル
同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
マイクロソフト、Visual Studio 2017正式リリース。コードを書きながら自動的にユニットテストを実行してくれるライブユニットテスティングなど
Visual Studio 2017はさまざまなプログラミング言語やプラットフォームに対応。C#や.NET Frameworkを用いたWindowsアプリケーションだけでなく、C++でLinux対応のアプリケーションを開発することも、TypeScriptでWebアプリケーションを開発することも、クラウドアプリケーションやモバイルアプリケーションの開発も可能です。 Visual Studio 2017ではインストールの時間を大幅に短縮。いままで2時間ほどかかっていたインストールを10分程度に短縮。 また必要な機能のみを必要なときに読み込む構造にすることで、起動時間も約半分になり、従来より軽快に動作すると説明されています。 開発者にとって注目すべき新機能のひとつは、C#かVisual Basicでコードを書いている場合、バックグラウンドで自動的にユニットテストを実行してくれる「ライブユニットテ
Behavior-driven development (BDD) in Haskell with Hspec
Behavior-driven development (BDD) in Haskell with Hspec In this tutorial, we implement the Luhn algorithm to validate credit card numbers while we show the advantages of using a combination of Haskell and Hspec to achieve techniques and principles of the BDD software development process. “Do the simplest thing that could possibly work” - Kent Beck But why BDD? Test Driven Development (TDD) is an i
Tests vs Types
13 January 2016 Tests vs. Types When should you use tests and when should you use types? What information and guarantees do we get for our efforts? I’ll walk through a simple, slightly contrived, example with Python, C, Haskell, and Idris. I’ll look at what you can tell about the implementation without knowing or examining it. I’m going to ignore ‘escape hatches’ which can explicitly violate the g
Stoneship > TDD Bypasses Your Brain
Written on March 16th, 2013. Here is a bold statement: writing code in a test-driven way bypasses your brain and makes you not think properly about what you are doing. Test-Driven Development (TDD) is a method of sofware development that puts a focus on writing tests up front to ensure that all code is covered by tests. TDD makes it very easy to write robust code fast, and also enables refactoring
「美しい，だから正しい」より「正しくて，あわよくば美しい」がよい - ぼくのぬまち 出張版
関数プログラミング実践入門．発売されました．電子版もあります． 今回は本書の副題に関する話題．本書の副題には「正しい」を使っている．実際に価値を提供するのは「正しい」コードなのだが，プログラミング関連文書でよく目にするコードに対する修飾は「美しい」なのだ．これは何故だろう． といっても，大抵の人は経験などから「美しい*1」コードならば読み易く間違えにくいということを知っている．なので，この点についてそう深く考える必要は無いようにも思われる．「美しい」コードは善である． しかし，「正しさ」についてあまりにも「美しさ」に頼るようでは危険だ．「美しいから正しい」ことがわかる状態はつまり「ヒトが目を凝らすから正しい」ことがわかる状態ということに他ならない．ヒトは間違える．目も頭も疲れる． 通常，「美しい」コードに保つのは存外コストを要する作業である．お仕事であればザックリと事業戦略の正しさがまず前
bliki: Unit Test
Unit testing is often talked about in software development, and is a term that I've been familiar with during my whole time writing programs. Like most software development terminology, however, it's very ill-defined, and I see confusion can often occur when people think that it's more tightly defined than it actually is. [1] Although I'd done plenty of unit testing before, my definitive exposure
Googleのテスト自動化の進化 - ワザノバ | wazanova
https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの
第57回 機能テストや性能テストをCabalで自動化
前回は、ライブラリや実行可能ファイルを提供するパッケージをCabalで作る方法を説明しました。Cabalには、パッケージをテストするための機能も用意されています。今回はこの機能の使い方を説明します。 テスト・プログラムを用意する まず、Cabalのテスト機能を使って実行するテスト・プログラムを用意しましょう。単純に標準出力や標準エラー出力にメッセージを表示するプログラムでは不十分です。テストの結果をきちんとCabalのテスト機能に伝えるプログラムにする必要があります。 第16回で説明したHUnitのrunTestTT関数、第17回で説明したQuickCheckのquickeCheck関数、verboseCheckなどは、標準出力や標準エラー出力を使ってテスト結果を報告します。このため、そのままCabalのテスト機能にテスト結果を伝えることができません。 Cabalのテスト機能では、テストの
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
New community features for Google Chat and an update on Currents
クックパッドはなぜ開発しやすいのか // Speaker Deck
Verifying Typeclass Laws in Haskell with QuickCheck
Testing Type Class Laws
jstolarek.com
Ian Cooper: TDD, where did it all go wrong
Reddit - Dive into anything
Why does my implementation of SVG arc conversion not pass QuickCheck?