測試驅動開發 測試前移

by Andrea Koutifaris

由Andrea Koutifaris

Test driven development has become popular over the last few years. Many programmers have tried this technique, failed, and concluded that TDD is not worth the effort it requires.

在過去的幾年中，測試驅動的開發變得很流行。 許多程序員嘗試了這種技術，但都失敗了，并得出結論認為TDD不值得它付出努力。

Some programmers think that, in theory, it is a good practice, but that there is never enough time to really use TDD. And others think that it is basically a waste of time.

一些程序員認為，從理論上講，這是一個好習慣，但是沒有足夠的時間真正使用TDD。 其他人則認為這基本上是浪費時間。

If you feel this way, I think you might not understand what TDD really is. (OK, the previous sentence was to catch your attention). There is a very good book on TDD, Test Driven Development: By Example, by Kent Beck, if you want to check it out and learn more.

如果您有這種感覺，我想您可能不了解TDD的真正含義。 (好的，前一句話是引起您的注意)。 如果您想了解一下并了解更多信息，那么肯特·貝克(Kent Beck)撰寫了一本關于TDD的非常好的書，即“ 測試驅動開發：示例” 。

In this article I will go through the fundamentals of Test Driven Development, addressing common misconceptions about the TDD technique. This article is also the first of a number of articles I’m going to publish, all about Test Driven Development.

在本文中，我將介紹測試驅動開發的基礎知識，以解決有關TDD技術的常見誤解。 本文也是我將要發表的有關測試驅動開發的許多文章的第一篇。

為什么要使用TDD？ (Why use TDD?)

There are studies, papers, and discussions about how effective TDD is. Even though it is definitely useful to have some numbers, I don’t think they answer the question of why we should use TDD in the first place.

關于TDD的有效性有研究，論文和討論。 盡管有一些數字絕對有用，但我認為他們沒有回答為什么我們應該首先使用TDD的問題。

Say that you are a web developer. You have just finished a small feature. Do you consider it enough to test this feature just by interacting manually with the browser? I don’t think it’s enough to rely just on tests done by developers manually. Unfortunately this means that part of the code is not good enough.

假設您是一名Web開發人員。 您剛剛完成了一個小功能。 您是否認為僅通過與瀏覽器手動交互就足以測試此功能？ 我認為僅依靠開發人員手動進行的測試是不夠的。 不幸的是，這意味著部分代碼不夠好。

But the consideration above is about testing, not TDD itself. So why TDD? The short answer is “because it is the simplest way to achieve both good quality code and good test coverage”.

但是上面的考慮是關于測試，而不是TDD本身。 那為什么要TDD？ 簡短的答案是“因為這是同時獲得高質量代碼和良好測試覆蓋范圍的最簡單方法”。

The longer answer comes from what TDD really is… Let’s start with the rules.

更長的答案來自TDD的真正含義。讓我們從規則開始。

游戲規則 (Rules of the game)

Uncle Bob describes TDD with three rules:

Bob叔叔用以下三個規則描述了TDD：

- You are not allowed to write any production code unless it is to make a failing unit test pass.-除非要通過失敗的單元測試，否則不允許編寫任何生產代碼。 - You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.-不允許編寫任何足以導致失敗的單元測試； 編譯失敗就是失敗。 - You are not allowed to write any more production code than is sufficient to pass the one failing unit test.-不允許編寫任何足以通過一項失敗的單元測試的生產代碼。

I also like a shorter version, which I found here:

我也喜歡一個簡短的版本，在這里可以找到：

- Write only enough of a unit test to fail.-僅編寫足夠的單元測試以失敗。 - Write only enough production code to make the failing unit test pass.-僅編寫足夠的生產代碼以使失敗的單元測試通過。

These rules are simple, but people approaching TDD often violate one or more of them. I challenge you: can you write a small project following strictly these rules? By small project I mean something real, not just an example that requires like 50 lines of code.

這些規則很簡單，但是接近TDD的人們經常違反其中一個或多個規則。 我向您挑戰：您可以嚴格遵循這些規則來編寫一個小項目嗎？ 在小型項目中，我指的是真實的東西，而不僅僅是一個需要50行代碼的示例。

Those rules define the mechanics of TDD, but they are definitely not everything you need to know. In fact, the process of using TDD is often described as a Red/Green/Refactor cycle. Let’s see what it is about.

這些規則定義了TDD的機制，但絕對不是您需要了解的所有內容。 實際上，使用TDD的過程通常被描述為紅色/綠色/重構周期。 讓我們看看它的含義。

紅色綠色重構周期 (Red Green Refactor cycle)

紅相 (Red phase)

In the red phase, you have to write a test on a behavior that you are about to implement. Yes, I wrote behavior. The word “test” in Test Driven Development is misleading. We should have called it “Behavioral Driven Development“ in the first place. Yes, I know, some people argue that BDD is different from TDD, but I don’t know if I agree. So in my simplified definition, BDD = TDD.

在紅色階段，您必須針對即將實現的行為編寫測試。 是的，我寫了行為 。 測試驅動開發中的“測試”一詞具有誤導性。 我們應該首先將其稱為“行為驅動的發展”。 是的，我知道，有些人認為BDD與TDD不同，但是我不知道我是否同意。 所以在我的簡化定義中，BDD = TDD。

Here comes one common misconception: “First I write a class and a method (but no implementation), then I write a test to test that class method”. It actually doesn’t work this way.

這是一個常見的誤解：“首先，我編寫了一個類和一個方法(但沒有實現)，然后編寫了一個測試以測試該類方法”。 實際上，這種方式行不通。

Let’s take a step back. Why does the first rule of TDD require that you write a test before you write any piece of production code? Are we TDD people maniacs?

讓我們退后一步。 為什么TDD的第一條規則要求您在編寫任何生產代碼之前先編寫測試？ 我們是TDD人瘋子嗎？

Each phase of the R.G.R. cycle represents a phase in the code’s lifecycle and how you might relate to it.

RGR周期的每個階段都代表代碼生命周期中的一個階段，以及您可能如何與之關聯。

In the red phase, you act like you’re a demanding user who wants to use the code that’s about to be written in the simplest possible way. You have to write a test that uses a piece of code as if it were already implemented. Forget about the implementation! If, in this phase, you are thinking about how you are going to write the production code, you are doing it wrong!

在紅色階段，您的行為就像是一個要求苛刻的用戶，希望使用將以最簡單的方式編寫的代碼。 您必須編寫一個使用一段代碼的測試，就像已經實現了一樣。 忘了執行！ 如果在此階段中您正在考慮如何編寫生產代碼，那么您做錯了！

It is in this phase where you concentrate on writing a clean interface for future users. This is the phase where you design how your code will be used by clients.

在此階段，您將專注于為將來的用戶編寫一個干凈的界面。 這是您設計客戶端如何使用代碼的階段。

This first rule is the most important one and it is the rule that makes TDD different from regular testing. You write a test so that you can then write production code. You don’t write a test to test your code.

第一條規則是最重要的規則，它是使TDD與常規測試不同的規則。 您編寫測試，以便隨后可以編寫生產代碼。 您無需編寫測試來測試您的代碼。

Let’s look at an example.

讓我們來看一個例子。

// LeapYear.spec.jsdescribe('Leap year calculator', () => { it('should consider 1996 as leap', () => { expect(LeapYear.isLeap(1996)).toBe(true); });});

The code above is an example of how a test might look in JavaScript, using the Jasmine testing framework. You don’t need to know Jasmine — it is enough to understand that it(...) is a test and expect(...).toBe(...) is a way to make Jasmine check if something is as expected.

上面的代碼是使用Jasmine測試框架在JavaScript中進行測試的示例。 您不需要了解茉莉花-足以了解it(...)是測試并且expect(...).toBe(...)是使茉莉花檢查某些東西是否符合預期的方法。

In the test above, I’ve checked that the function LeapYear.isLeap(...) returns true for the year 1996. You may think that 1996 is a magic number and is thus a bad practice. It is not. In test code, magic numbers are good, whereas in production code they should be avoided.

在上面的測試中，我檢查了函數LeapYear.isLeap(...)在1996年返回true 。您可能認為1996是個神奇的數字，因此是一種不好的做法。 它不是。 在測試代??碼中，幻數是好的，而在生產代碼中則應避免。

That test actually has some implications:

該測試實際上具有一些含義：

• The name of the leap year calculator is LeapYear

  year年計算器的名稱是LeapYear

• isLeap(...)is a static method of LeapYear

  isLeap(...)是LeapYear的靜態方法

• isLeap(...) takes a number (and not an array, for example) as an argument and returns true or false .

  isLeap(...)以數字(而不是數組)作為參數，并返回true或false 。

It’s one test, but it actually has many implications! Do we need a method to tell if a year is a leap year, or do we need a method that returns a list of leap years between a start and end date? Are the name of the elements meaningful? These are the kinds of questions you have to keep in mind while writing tests in the Red phase.

這是一項測試，但實際上有很多含義！ 我們是否需要一種方法來判斷年份是否為a年，或者是否需要一種方法來返回開始日期和結束日期之間的of年列表？ 元素的名稱有意義嗎？ 在Red階段編寫測試時，您必須牢記這些問題。

In this phase, you have to make decisions about how the code will be used. You base this on what you really need at the moment and not on what you think may be needed.

在此階段，您必須決定如何使用代碼。 您基于當前真正需要的內容，而不是您認為可能需要的內容。

Here comes another mistake: do not write a bunch of functions/classes that you think you may need. Concentrate on the feature you are implementing and on what is really needed. Writing something the feature doesn’t require is over-engineering.

這是另一個錯誤：不要編寫您認為可能需要的函數/類。 專注于您要實現的功能以及真正需要的功能。 編寫功能不需要的東西是過度設計。

What about abstraction? Will see that later, in the refactor phase.

那抽象呢？ 稍后會在重構階段看到這一點。

綠相 (Green phase)

This is usually the easiest phase, because in this phase you write (production) code. If you are a programmer, you do that all the time.

這通常是最簡單的階段，因為在此階段中您將編寫(生產)代碼。 如果您是一名程序員，那么您將一直這樣做。

Here comes another big mistake: instead of writing enough code to pass the red test, you write all the algorithms. While doing this, you are probably thinking about what is the most performing implementation. No way!

這是另一個大錯誤：您沒有編寫足夠的代碼來通過紅色測試，而是編寫了所有算法。 在執行此操作時，您可能正在考慮什么是性能最高的實現。 沒門！

In this phase, you need to act like a programmer who has one simple task: write a straightforward solution that makes the test pass (and makes the alarming red on the test report becomes a friendly green). In this phase, you are allowed to violate best practices and even duplicate code. Code duplication will be removed in the refactor phase.

在這一階段，您需要像一名程序員一樣扮演一個簡單的任務：編寫一個簡單的解決方案，使測試通過(并使測試報告上的警報紅色變為友好的綠色)。 在此階段，您可以違反最佳做法，甚至可以重復代碼。 代碼重復將在重構階段刪除。

But why do we have this rule? Why can’t I write all the code that is already in my mind? For two reasons:

但是為什么要有這個規則？ 為什么我不能編寫所有已經想到的代碼？ 有兩個原因：

• A simple task is less prone to errors, and you want to minimize bugs.
  一個簡單的任務不太容易出錯，而您想減少錯誤。
• You definitely don’t want to mix up code which is under testing with code that is not. You can write code that is not under testing (aka legacy), but the worst thing you can do is mixing up tested and untested code.
  您絕對不希望將正在測試的代碼與沒有測試的代碼混合在一起。 您可以編寫未經測試的代碼(也稱為舊版代碼)，但是最糟糕的事情是將經過測試和未經測試的代碼混合在一起。

What about clean code? What about performance? What if writing code makes me discover a problem? What about doubts?

干凈的代碼呢？ 性能如何？ 如果編寫代碼使我發現問題怎么辦？ 懷疑呢？

Performance is a long story, and is out of the scope of this article. Let’s just say that performance tuning in this phase is, most of the time, premature optimization.

性能是一個很長的故事，超出了本文的范圍。 可以說，在大多數情況下，此階段的性能調整是過早的優化。

The test driven development technique provides two others things: a to-do list and the refactor phase.

測試驅動的開發技術提供了另外兩件事：待辦事項列表和重構階段。

The refactor phase is used to clean up the code. The to-do list is used to write down the steps required to complete the feature you are implementing. It also contains doubts or problems you discover during the process. A possible to-do list for the leap year calculator could be:

重構階段用于清理代碼。 待辦事項列表用于寫下完成您正在實現的功能所需的步驟。 它還包含您在此過程中發現的疑問或問題。 year年計算器的可能工作清單可能是：

Feature: Every year that is exactly divisible by four is a leap year, except for years that are exactly divisible by 100, but these centurial years are leap years if they are exactly divisible by 400.- divisible by 4- but not by 100- years divisible by 400 are leap anywayWhat about leap years in Julian calendar? And years before Julian calendar?

The to-do list is live: it changes while you are coding and, ideally, at the end of the feature implementation it will be blank.

待辦事項列表是實時的：您在編碼時會更改，并且理想情況下，在功能實施結束時它將為空。

重構階段 (Refactor phase)

In the refactor phase, you are allowed to change the code, while keeping all tests green, so that it becomes better. What “better” means is up to you. But there is something mandatory: you have to remove code duplication. Kent Becks suggests in his book that removing code duplication is all you need to do.

在重構階段，您可以更改代碼，同時使所有測試保持綠色，從而使其變得更好。 “更好”的意思取決于您。 但是有一些強制性的要求： 您必須刪除代碼重復 。 肯特·貝克斯(Kent Becks)在他的書中建議，消除代碼重復是您所要做的全部。

In this phase you play the part of a picky programmer who wants to fix/refactor the code to bring it to a professional level. In the red phase, you’re showing off your skills to your users. But in the refactor phase, you’re showing off your skills to the programmers who will read your implementation.

在這個階段，您扮演著一個挑剔的程序員的角色，他想修復/重構代碼以使其達到專業水平。 在紅色階段，您向用戶展示了自己的技能。 但是在重構階段，您正在向將閱讀您的實現的程序員展示您的技能。

Removing code duplication often results in abstraction. A typical example is when you move two pieces of similar code into a helper class that works for both the functions/classes where the code has been removed.

刪除代碼重復通常會導致抽象。 一個典型的例子是，當您將兩個相似的代碼片段移到一個幫助程序類中，該幫助程序類適用于已刪除代碼的兩個函數/類。

For example the following code:

例如下面的代碼：

class Hello { greet() { return new Promise((resolve) => { setTimeout(()=>resolve('Hello'), 100); }); }}class Random { toss() { return new Promise((resolve) => { setTimeout(()=>resolve(Math.random()), 200); }); }}new Hello().greet().then(result => console.log(result));new Random().toss().then(result => console.log(result));

could be refactored into:

可以重構為：

class Hello { greet() { return PromiseHelper.timeout(100).then(() => 'hello'); }}class Random { toss() { return PromiseHelper.timeout(200).then(() => Math.random()); }}class PromiseHelper { static timeout(delay) { return new Promise(resolve => setTimeout(resolve, delay)); }}const logResult = result => console.log(result);new Hello().greet().then(logResult);new Random().toss().then(logResult);

As you can see, in order to remove thenew Promise and setTimeout code duplication, I created a PromiseHelper.timeout(delay) method, which serves both Hello and Random classes.

如您所見，為了刪除new Promise和setTimeout代碼重復項，我創建了一個PromiseHelper.timeout(delay)方法，該方法同時提供Hello類和Random類。

Just keep in mind that you cannot move to another test unless you’ve removed all the code duplication.

請記住，除非您刪除了所有重復的代碼，否則您無法繼續進行其他測試。

最后考慮 (Final considerations)

In this section I will try to answer to some common questions and misconceptions about Test Drive Development.

在本節中，我將嘗試回答有關測試驅動開發的一些常見問題和誤解。

• T.D.D. requires much more time than “normal” programming!
  與“普通”編程相比，TDD需要更多的時間！

What actually requires a lot of time is learning/mastering TDD as well as understanding how to set up and use a testing environment. When you are familiar with the testing tools and the TDD technique, it actually doesn’t require more time. On the contrary, it helps keep a project as simple as possible and thus saves time.

實際上需要大量時間的是學習/掌握TDD以及了解如何設置和使用測試環境。 當您熟悉測試工具和TDD技術時，實際上并不需要更多時間。 相反，它有助于使項目盡可能簡單，從而節省時間。

• How many test do I have to write?
  我必須寫多少個測試？

The minimum amount that lets you write all the production code. The minimum amount, because every test slows down refactoring (when you change production code, you have to fix all the failing tests). On the other hand, refactoring is much simpler and safer on code under tests.

使您可以編寫所有生產代碼的最小數量。 最小數量，因為每個測試都會減慢重構速度(更改生產代碼時，必須修復所有失敗的測試)。 另一方面，在測試中的代碼重構更加簡單和安全。

• With Test Driven Development I don’t need to spend time on analysis and on designing the architecture.
  通過測試驅動開發，我不需要花時間在分析和設計體系結構上。

This cannot be more false. If what you are going to implement is not well-designed, at a certain point you will think “Ouch! I didn’t consider…”. And this means that you will have to delete production and test code. It is true that TDD helps with the “Just enough, just in time” recommendation of agile techniques, but it is definitely not a substitution for the analysis/design phase.

這不可能是錯誤的。 如果您要實施的方案設計不當，則在某些時候您會認為“好極了！ 我沒有考慮……”。 這意味著您將必須刪除生產和測試代碼。 TDD確實有助于敏捷技術的“足夠，及時”建議，但絕對不能替代分析/設計階段。

• Should test coverage be 100%?
  測試覆蓋率應該是100％嗎？

No. As I said earlier, don’t mix up tested and untested code. But you can avoid using TDD on some parts of a project. For example I don’t test views (although a lot of frameworks make UI testing easy) because they are likely to change often. I also ensure that there is very a little logic inside views.

不，正如我之前說的，不要混淆經過測試和未經測試的代碼。 但是您可以避免在項目的某些部分上使用TDD。 例如，我不測試視圖(盡管許多框架使UI測試變得容易)，因為它們可能經常更改。 我還確保視圖內部有一點邏輯。

• I am able to write code with very a few bugs, I don’t need testing.
  我能夠編寫帶有幾個錯誤的代碼，不需要測試。

You may able to to that, but is the same consideration valid for all your team members? They will eventually modify your code and break it. It would be nice if you wrote tests so that a bug can be spotted immediately and not in production.

您也許可以做到這一點，但是對您所有團隊成員而言，相同的考慮因素是否有效？ 他們最終將修改您的代碼并將其破壞。 如果您編寫測試，以便可以立即發現錯誤而不是在生產環境中，那將是很好的。

• TDD works well on examples, but in a real application a lot of the code is not testable.
  TDD在示例中效果很好，但是在實際應用中，很多代碼是不可測試的。

I wrote a whole Tetris (as well as progressive web apps at work) using TDD. If you test first, code is clearly testable. It is more a matter of understanding how to mock dependencies and how to write simple but effective tests.

我使用TDD編寫了完整的Tetris(以及工作中的漸進式Web應用程序)。 如果您先進行測試，則代碼顯然是可測試的。 更多的問題是了解如何模擬依賴關系以及如何編寫簡單而有效的測試。

• Tests should not be written by the developers who write the code, they should be written by others, possibly QA people.
  測試不應由編寫代碼的開發人員編寫，而應由其他人(可能是質量檢查人員)編寫。

If you are speaking about testing your application, yes it is a good idea to ask other people to test what your team did. If you are speaking about writing production code, then that’s the wrong approach.

如果您要談論測試您的應用程序，是的，最好請其他人測試您的團隊做了什么。 如果您要談論編寫生產代碼，那是錯誤的方法。

下一步是什么？ (What’s next?)

This article was about the philosophy and common misconceptions of TDD. I am planning to write other articles on TDD where you will see a lot of code and fewer words. If you are interested on how to develop Tetris using TDD, stay tuned!

本文介紹了TDD的哲學和常見誤解。 我打算在TDD上寫其他文章，您會看到很多代碼和更少的單詞。 如果您對如何使用TDD開發俄羅斯方塊感興趣，請繼續關注！

翻譯自: https://www.freecodecamp.org/news/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2/

測試驅動開發 測試前移

總結

以上是生活随笔為你收集整理的测试驱动开发 测试前移_测试驱动开发：它是什么，什么不是。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。