###### tags: `work`

# 證明testing不必全做

## 結論
只要方法正確，deploy後testing做全套是浪費時間。測試只應該做該version有的內容,測試其他內容本質上與浪費人生無異。🙂

## 方法

首先, 該證明基於以下幾個***假設***：

(1) 你***每次*** develop時都有測試(該version的function)，確保重要function在localhost不會出事，然後才deploy到prod。
(2) 每一個version之間勿定是 ***獨立*** 的。(e.g. 每次push都是完成該feature的版本而非做一半的版本)
(3) 你沒有搞亂任何environment/config setting於deployment的環境。

*其中(1)，(3)為可遵循的原則，(2)為邏輯自洽的真理。*

如按照以上3點，以節省你的時間，不必測試所有function，deploy後也不會發生任何事，相信我。

### 證明（反證法）:

假設你沒有違反以上3點做,deploy後還是爆炸了。

只有以下可能性:

即然有測試清楚該版本feature正常(1),且每個version獨立(2)， 出事的位置只能是上一版本，或其他版本，設為k，而k版本也應有測試清楚(1)，也只能是其他版本，由於版本是有限的，不可能追溯到時間盡頭，因此必定有一版本出事，即衍生以下情況。

Case 1:
如該project由頭到尾都由一人負責(即你)，則你在deploy該版本時違反以上3點，此處與假設產生矛盾。

Case 2:
如project由多人做成，出事版本為他人版本，則不會產生矛盾，但該問題並非由你直接造成，非你能力所及，如他人按照以上3點做develop，問題則不會出現。

## 限制
有人會提出以下反駁
A. 特定功能可能會與其他部分有相依性，因此需要測試其他部分以確保整個系統正常運作
B. 有些錯誤可能只會在特定的環境或使用情境下出現，因此需要在這些情況下進行測試
C. 在某些情況下，測試可能是必需的，例如對於安全性和可靠性要求高的系統
D. 雖然每個版本都是獨立的，但是如果前一個版本中的問題對後續版本造成了影響，那麼可能需要測試整個系統以確保問題已經被解決。

以下是回應：
- A,特定功能可能會與其他部分有相依性，但是我們可以通過將相依的部分單獨測試，以確保它們的正常運作。這樣，即使存在相依關係，版本之間仍然是獨立的。這也是前提假設(2)所描述的。`see next section`
- C，因為即使存在結構性問題，也並不意味著需要測試整個系統。例如，考慮一個車輛的系統，如果我們需要測試車輛的引擎，那麼我們只需要單獨測試引擎，而不需要測試整輛車。即使在一些特定的情況下，車輪陷入流沙或雪地，這些問題與車頭燈無關，因此不需要測試車頭燈。我們只需要在測試中考慮可能出現的特定情況，以確保系統的正常運作。因此，即使存在結構性問題，版本之間仍然是獨立的，並且可以單獨測試和部署每個版本。
- Ｂ和D，特定的錯誤可能只會在特定的環境或使用情況下出現，但是這並不意味著需要在每種情況下進行測試。相反，可以通過針對可能出現問題的情況進行測試，以確保版本的正常運作。同時，即使存在這些特定的情況，版本之間仍然是獨立的，每個版本都可以單獨測試和部署。

"特定情況"這個說法的說服力不足，因為特定情況是相對的，不確定的，複雜的。我們無法預測所有可能的情況，而所有情況無法在有限時間內解決。

## 再證-前題2

我們可以通過以下邏輯證明，即使版本之間存在相依關係，它們在邏輯上仍然是獨立的。

假設應用程序中有兩個功能A和B，其中B依賴於A的正常運作。
e.g.

假設有兩個版本v1和v2，其中v2包括對A的更改。我們可以將應用程序分成兩部分：A和B。由於B依賴於A的正常運作，我們可以將B分成兩個部分：B1和B2。B1是B的主要功能，而B2是B依賴於A的部分。

Case 1:
version 1:A
version 2:A(修改後) + B2,B1

由於B依賴於修改後的A。因此，即使存在相依關係，版本之間仍必然是獨立的。若v2的A炒了，只有可能是修改後出問題，而根據(1)，你應該測試你修改了的內容。

Case 2:
version 1:A(未修改)
version 2:A(未修改) + B2,B1

由於B依賴於A，因此如B炒了，而B本身無問題，只能是A問題，而根據(1)，A在之前版本已被測試(1)。

---
有沒有可能是B1,B2整炒未修改的A呢?
沒有，邏輯上來說。

如B1,B2會整炒未修改的A，表示A依賴於B運行，以下是圖像。

時間線上不能吻合，A存在時B不存在，A如何依賴於當時不存在的B2運行呢。

--- Mr. Console Log

# English version (中英對照，仲唔死?)
## Overview
No Need to Test Everything in Deployment
Conclusion: As long as the method is correct, running a full suite of tests after deployment is a waste of time. Tests should only be performed on the contents of the specific version, and testing other contents is essentially no different from wasting one's life.

## Method
First, this proof is based on the following assumptions:

(1) You test each version's functionality during development (ensuring critical functions work on localhost) before deploying to production.
(2) Each version is independent of other versions (e.g., every push is a complete feature version, not a half-done version).
(3) You have not messed up any environment/config settings in the deployment environment.

If you follow these three points, you can save time by not testing all functions. Nothing will go wrong after deployment, trust me.

### Proof (by contradiction):
Assuming you have not violated the three points above, and yet, the deployment still fails.

There are only the following possibilities:

Since the features of the current version have been thoroughly tested (1), and each version is independent (2), the problem must have arisen in a previous version or another version, denoted as k. Since version k should also have been thoroughly tested (1), the problem must lie in another version. As the number of versions is finite, it is impossible to trace back infinitely, so there must be a problematic version, leading to the following cases.

Case 1:
If the entire project is handled by one person, then you have violated one of the three points during the deployment of that version. This contradicts the initial assumption.

Case 2:
If the project was completed by multiple people and the problematic version was someone else's, there is no contradiction. However, the problem wasn't directly caused by you and is beyond your control or responsibility. If others follow the three points during development, the problem won't occur.