NO TEST,
NO MERGE

テストはバグが存在しないことではなく、
バグが存在することを示すものである

テストは、健康診断
と意義が同じ！！

クリーンアーキテクチャでは
こう言っています

あらゆるレベルにおいて

ソフトウェアは科学のように

「反証可能性」によって動かされている。

反証可能性

Karl Raimund Poppr

1902-1994

反論できる余地があるものだけが、意味のある論文

魔女は存在すると思いますか？

魔女が存在するかどうかを
議論する場合に

魔女が存在することを
「証明する論文」を書く

「魔女が存在"しない"ことを
　証明できないのだから、
　魔女は存在するのだ」と
　主張する

 

VS

魔女が存在することを
「証明する論文」であれば、
その魔女が本当に魔女なのか、
チェックをして
「反論をできる可能性」
がある。
これが科学の条件。

「魔女が存在"しない"ことを
　証明できないのだから、
　魔女は存在するのだ」

という主張は、
反論することができないので、

反証性がないので、

科学性を欠いており価値がないということ

反証可能性

Karl Raimund Poppr

1902-1994

「テストでアプリケーションが
　正常に動作することを
　証明できないのだから、
　バグはテストを書いてもどうせ存在する。
　だから書かなくてもいい。」

という主張には意味がない
ということ（もいえませんか？）

あらゆるレベルにおいて、
ソフトウェアは科学のように、「反証可能性」によって
動かされている。

ソフトウェアアーキテクトは、
簡単に反証できる（テスト可能な）
モジュール、コンポーネント、サービスを
定義しようとする。

Method・Component は
簡単に反証できる
（テスト可能な）

粒度であるべきではないか
 

テストが書ければ、
どういう粒度、
コーディング様式でも
いい

コンポーネントの
テストは書くべきか

DOM のテスト難しい問題

かけるなら書いた方がいい

React にも Vue にも Component Test のための Utility が用意されている。書けることは書ける。

しかし

Component のテストは

いまいちわからない！

まだ Method や Vuex のテストの
書き方がわかってきた段階なので、Component のテストは
わからない。

複雑になりがちな場所には必ずテストを
 

具体的には

  • API をたたくメソッド
  • 受け取ったデータを加工してテーブル用の値を作るメソッド
  • Vuex の実行

テストを
書きやすくするコツ

関数型
副作用ゼロ

const doSomething = (param) => {
    return param * 2
}

const res = doSomething(10)
const doSomething = () => {
    x = x * 2
}

let x = 4

doSomething()

副作用
バリある

テストかける

const doSomething = (param) => {
    return param * 2
}

const res = doSomething(10)

test('Yes, We can.', () => {
    const res = doSomething(100)
    expect(res).toEqual(200)
})
const doSomething = () => {
    x = x * 2
}
let x = 4

test("No, We can't...", () => {
    doSomething()
    expect(x).toEqual(8) // ?
    // x に初期値として何が入っているのかわからない
    // x が存在するとも限らない
})

難しい

TDD である必要はないが
反証可能性のある

科学的なコードを！

NO TEST,
NO MERGE

Made with Slides.com