失敗から学ぶAPIファースト / API first learning from failure
Presentation Slides for ServerlessDays Tokyo 2023 ( connpass) Session Title: 失敗から学ぶAPIファースト ~ 正しいデザインからはじめるアーキテクチャ選定、開発ライフサイクル＆コラボレーション Session Video: [ServerlessDays Tokyo 2023] 失敗から学ぶAPIファースト / 川崎庸市 Date: 2023/09/23 Update history - 2023/09/24: fix typo - 2023/12/13: p19 表現を更新「APIファースト」→「APIファースト開発モデル」
private 関数にもテストを書きたいとき
「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を
今度こそユニットテストを書き始めるために
はじめに Unit Testが大事、ということ自体はあまり異論はないと思うのですが、最初からTDDがしっかりできてるような現場ならいざ知らず、そうではない場合は中々うまく入れれない事も多くあります。なのでこうすると導入しやすい、という観点で以下の動画でそのあたりのことを話したのですが、補足も含めて記事でもまとめておきたいと思います。 これはユニットテストですか？ ユニットテストとは？ ユニットテストとは何でしょうか？ 一応、テストの資格試験を実施しているISTQBの定義では以下のように定義されます。 component testing (unit testing) A test level that focuses on individual hardware or software components. Synonyms: module testing, unit testing この
単体テストは「2：8の法則」でだいたい品質が担保できる 網羅率・期待値を担保した適切なソリューション
上流品質を担保するために必要な3つのこと 高橋寿一氏（以下、高橋）：Dailyで上流品質を担保するために必要な3つのことです。単体テスト、リファクタリング、要求仕様、ユーザーストーリーのテストケース展開という3つのアクティビティをしっかりやっていただくと、上流でも品質がかなり担保されていくんじゃないのかなと思っています。 単体テストに関しては、基本的には「網羅率を担保してください」みたいなことなので、シンプルです。ただ、まだまだ知られていませんが、0から70パーセントとか80パーセントに持ってくるのは地獄のような作業なので、だいたいみなさん諦めちゃうんです。 でも、テクノロジーが進んでいるのでそこまでやる必要はなくて、「2：8の法則」ですよね。ソフトウェア全体の2割の危ないところだけをテストすれば、だいたい品質は担保されますという。超いい加減な言い方をしましたが、そういうものがあります。
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
「スタートアップだからテストを書かない」は正しいか - An Epicurean
スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア
組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
テストコードが増えるとバグは減るのだろうか？ / Does more test code mean fewer bugs? - Speaker Deck
Transcript ςετίʔυ͕૿͑ΔͱόάݮΔͷͩΖ͏͔ʁ�� ʮ���ˠ������ʯͰݟ͑ͨੈքͷ� גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦�J04νʔϜ� ໊औ�߂ฏ Copyright © ZOZO Technologies, Inc. © ZOZO Technologies, Inc. גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦� J04νʔϜ ໊औ�߂ฏ 20192݄ΑΓݱ৬ɻ ZOZOTOWN iOSΞϓϦͷ։ൃΛ͍ͯ͠·͢ɻ झຯͰݸਓ։ൃɻ 2 © ZOZO Technologies, Inc. 3 ���ˠ������ ʹ ͜ͷ�΄ͲͰ૿Ճͨ͠ςετΧόϨοδͷׂ߹ © ZOZO Technologies, Inc. 4 ���ˠ������ ����� ˞ܭଌର͜ͷ�ͷ։ൃͰؔ༩ͨ͠ϑΝΠϧʹߜ͍ͬͯΔ © ZOZO Te
The Testing Renaissance
Don’t you love to crank code? As developers, we love to refactor; we love to be productive. As managers, how can we let the coding cowboys on our team be free, while maintaining code quality? At Twitter, we’ve been experimenting with feature testing. There are at least seven teams doing some form of feature testing of their services. Some of these teams have even discarded most of their single cla
xUnit Test Patternsから学ぶ12個のユニットテストの原則 - Qiita
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
Tips to Speed up Your Phpunit Tests - Laravel News
{ if (! this.initialized) { search.start(); this.initialized = true; } if (value) { setTimeout(() => { this.$el.querySelector('input').focus(); }, 100); } }); }, }" x-dialog x-model="searchModalIsOpen" x-cloak class="fixed inset-0 z-10" @keydown.slash.meta.window="searchModalIsOpen = !searchModalIsOpen" @keydown.k.meta.window="searchModalIsOpen = !searchModalIsOpen" @keydown.escape.window="searchM
Lean Testing or Why Unit Tests are Worse than You Think
Testing is a controversial topic. People have strong convictions about testing approaches. Test Driven Development is the most prominent example. Clear empirical evidence is missing which invites strong claims. I advocate for an economic perspective towards testing. Secondarily, I claim that focussing too much on unit tests is not the most economic approach. I coin this testing philosophy Lean Tes
UI Recorder - node.js製のSelenium IDE代替 MOONGIFT
Selenium IDEが最新のFirefoxで動かなくなりました。これに伴い、新しいAPIで動くIDEも開発がスタートしたようですが、それを待つのも辛いでしょう。かといって旧バージョンを使い続けるのも問題です。 そこで使ってみたいのがUI Recorderです。新しく登場したSelenium IDEライクなWebブラウザの操作記録ソフトウェアです。 UI Recorderの使い方 UI Recorderではまずディレクトリを作って初期化します。 $ uirecorder init __ ______ ____ __ / / / / _/ / __ \___ _________ _________/ /__ _____ / / / // / / /_/ / _ \/ ___/ __ \/ ___/ __ / _ \/ ___/ / /_/ // / / _, _/ __/ /__/ /_/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why Most Unit Testing is Waste — Tests Don’t Improve Quality: Developers Do
「質」のいいユニットテストを書くためのプラクティス / practices to write better unit test