為什麼要寫測試

在過去程式人員往往不負責測試，測試由專門的測試人員來負責。但近年來有人提倡測試驅動開發(Test-driven development TDD)，就是所謂先寫測試，再寫程式的做法。提倡者認為，在開發前先將測試部分完成，可以幫助我們提高代碼品質。

對於TDD我過去並未實踐過，因此也藉這次的專案來練習並體驗一下TDD的優缺點。而TDD的程式設計流程稱為「紅燈／綠燈／重構」循環（Red/Green/Refactor），具體實現的方法為

1. 先訂定目標，並寫測試
2. 由於這時候還沒有實現，測試一定會失敗(紅燈)
3. 實作"剛好可以通過測試的程式"
4. 再次執行程式，得到程式通過(綠燈)
5. 重構程式
   透過以上方法，我們可以避免冗餘的程式碼，同時可以確保程式碼品質，在過程中如果遇到問題也可以盡早發現問題所在，而TDD的最大的好處之一就是我們可以安心的"重構"，沒有測試的程式碼是不能動的(*見下圖)，因為我們不知道會不會動下去就壞掉。

GTest

目前有許多開源的測試框架，可以幫助我們更容易的撰寫測試，而筆者這裡透過GTest來進行測試的撰寫。GTest，全名為Google Test，是Google開發的一個用於C++單元測試的開源測試框架。它旨在幫助C++開發人員編寫可靠的、可維護的測試代碼，並提供了豐富的斷言和測試組織工具。GTest是C++單元測試中最流行的框架之一，它使測試代碼的編寫和運行變得更加容易。並且由於CMake本身的CTest支援GTest的使用，所以透過GTest寫的測試，可以透過CTest與CMake結合。

GTest安裝方法

git clone https://github.com/google/googletest.git
cd gtest
cd googletest
mkdir build
cd build
cmake ..
make
sudo make install

安裝完成後，我們就可以開始透過GTest的框架撰寫程式。

我們在ALISS的src底下新增 test_main.

#include <gtest/gtest.h>

TEST(MyTestSuite, MyTestCase) { #call  gtest macro
    ASSERT_TRUE(true);
}

這個測試的想法很簡單，那就是我猜true是TRUE，我們先透過這個測試確認編得過。
接下來我們修改CMakeList，加入GTest Library。

cmake_minimum_required(VERSION 2.8)

project(ALISS)

find_package(GTest REQUIRED)
set(CMAKE_CXX_STANDARD 11)


set(SOURCE_FILES src/main.cxx)

set(TEST_FILES src/test_main.cxx)

add_executable(ALISS ${SOURCE_FILES})
add_executable(ALISS_TEST ${TEST_FILES})
target_link_libraries(ALISS_TEST gtest GTest::GTest GTest::Main)

add_test(MAIN_TEST ALISS_TEST)     

之後我們重新編譯，確認可以編譯成功。
在Build底下可以看到ALISS_TEST，執行。

[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from MyTestSuite
[ RUN      ] MyTestSuite.MyTestCase
[       OK ] MyTestSuite.MyTestCase (0 ms)
[----------] 1 test from MyTestSuite (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 1 test.

可以看到第一個測試被順利執行，並且確認為PASSED。

最後我們將測試加到JenkinsFlow，

並記得在Jenkins server安裝GTest，確認順利執行就完成我們第一支測試啦

碎碎念 : 先將框架完成，之後就可以開始寫測試了。原本計畫今天要來寫ELF Loader但不小心篇幅太長了，明天再戰~(逃)