iT邦幫忙

2021 iThome 鐵人賽

DAY 3
0
Modern Web

每天一篇文章系列 第 3

03. Unit Test x PHPUnit x FizzBuzz

  • 分享至 

  • twitterImage
  •  

Fizz Buzz 是個小朋友的遊戲,小朋友們依序報數,但當遇到三的倍數要喊 fizz、五的倍數喊 fuzz,遇到既是三也是五的倍數要喊 fizzbuzz。

有人小時候玩過嗎?我想這個遊戲應該在成年人間比較流行(以面試題的型式)...

來玩 FizzBuzz ㄅ

Unit Test

好的這位大朋友,讓我們...打開 tests/Unit 資料夾,一起用單元測試來玩...

tests/Unit 裡面有一個內建的 ExampleTest 檔案。
assertTrue() 會檢查傳入的參數是否是 true,是則回傳 true。

<?php

namespace Tests\\Unit;

use PHPUnit\\Framework\\TestCase;
use App\\My\\Service\\TestService;

class ExampleTest extends TestCase
{
    public function testSomethingIsTrue()
    {
        $this->assertTrue(true);
    }
}

這位大朋友您別急,我們再學一個 assertSame(),這個函式會檢查傳入的兩個參數是否是相等,是則回傳 true。
下面是我寫了一個會回傳輸入的函式,然後用 assertSame 檢查。

public function testSomethingIsTrue()
{
    $input = "1";
    $output = $this->fizzbuzz($input);
    $this->assertSame($input,$output);
}

private function fizzbuzz($input) {
    return $input;
}

接下來我們需要一個可以自動輸測資的工具。
在 test function 上加上 @dataProvider 可以透過連結的函式餵入參數。
我們把遊戲規則寫進去ㄅ。

 /**
 * @dataProvider data
 */
public function testSomethingIsTrue($input, $expect)
{
    $output = $this->fizzbuzz($input);
    $this->assertSame($output, $expect);
}

public function data()
{
    return [
        [ "1", "1" ],
        [ "3", "fizz" ],
        [ "5", "buzz" ],
        [ "15", "fizzbuzz" ]
    ];
}

private function fizzbuzz($input) {
    return $input;
}

終於等到紅燈了 ^_^

https://ithelp.ithome.com.tw/upload/images/20210917/201397453dIpXXkX5m.jpg

接下來要做的就是把 fizzbuzz 函式改對。

private function fizzbuzz($input) {

    $input = (int) $input;

    if( $input % 15 == 0 ){
        return 'fizzbuzz';
    }

    if( $input % 3 == 0 ){
        return 'fizz';
    }

    if( $input % 5 == 0 ){
        return 'buzz';
    }

    return (string) $input;

}

搭拉!

參考
https://phpunit.readthedocs.io/en/9.5/writing-tests-for-phpunit.html

AAA pattern

在這個範例裡,我們使用到了 3A 原則,也就是 Arrange-Act-Assert

Arrange = 準備受測物件、參數、預期結果
Act = 執行受測方法
Assert = 驗證執行結果與預測結果是否一致

我們在 data provider 準備測資,執行 fizzbuzz 函式,assert 驗證結果。

紅燈、綠燈、重構

流程上,有使用到 TDD 的部分概念。
我們先寫遊戲規則,再來改寫函式。

這樣對工程師方便的地方是我們在開發時很清楚什麼時候可以跟 PM 說「我寫完啦」,不必擔心有什麼沒考慮到。

另一點,我們把遊戲規則白紙黑字的寫下來放進程式碼版空了,日後如果沒時間補文件,至少我們還有測試程式可以參考。

聽起來很棒,為什麼有人不這麼做呢?

最常見的情況是需求太常變動,或是沒有能列規格的 PM。
才剛通過了測試,驗收的人又覺得要改一改、補一補,這種情況下的測試程式就失去了意義。


上一篇
02. Hello x Test x Test Pyramid
下一篇
04. Unit Test x Cart Class
系列文
每天一篇文章30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Ken Chen
iT邦新手 4 級 ‧ 2021-09-18 09:56:50

感謝分享

終於等到紅燈了 ^_^

原來等到紅燈是值得開心一件事XD?! 看來哪隻股票漲停了 大誤~~~~

fizz
buzz
fizzbuzz~~~~

我要留言

立即登入留言