tdd測試驅動開發課程介紹

by Luca Piccinelli

通過盧卡·皮奇內利

測試驅動開發很難！ 這是不為人知的事實。 (Test Driven Development is hard! This is the untold truth about it.)

These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD). And you probably hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is to do them.

這些天，您閱讀了大量有關測試驅動開發(TDD)的所有優點的文章。 而且您可能會在技術會議上聽到很多演講，告訴您“做測試！”，以及進行這些測試有多酷。

And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). Tests are a MUST! The typical advantages we list when it comes to talking about TDD are real:

你知道嗎？ 不幸的是，它們是正確的(不一定與“酷”部分有關，而與有用部分有關)。 測試是必須的 ！ 在談到TDD時，我們列出的典型優勢是真實的：

• You write better software
  您編寫更好的軟件
• You have protection from breaking the world when new features are introduced
  引入新功能后，您可以免受破壞
• Your software is self documented
  您的軟件是自我記錄的
• You avoid over-engineering
  避免過度設計

Even if I’ve always agreed with these advantages, there was a time when I thought that I didn’t need TDD to write good and maintainable software. Of course, now I know I was wrong, but why did I have this idea despite the shiny magic of the pros? The reason is just one: and let me ask Rihanna to say it for me…

即使我一直都同意這些優點， 但有時我還是以為我不需要TDD來編寫優秀且可維護的軟件。 當然，現在我知道我做錯了，但是盡管職業選手閃閃發光，我為什么仍然有這個主意？ 原因只有一個：讓我請蕾哈娜(Rihanna)為我說一下……

成本！ (The Cost!)

It costs a lot! Probably someone is thinking “but it costs even more if you don’t do the tests” — and this is right, too. But these two costs come at different times:

花費很多！ 可能有人在考慮“ 但如果不進行測試，則成本更高 ” –這也是正確的。 但是，這兩個成本發生在不同的時間：

• you do TDD ? you have a cost now.

  你做TDD?現在就要花錢了 。

• You don’t do TDD ? you will have a cost in the future.

  您不做TDD? 將來會付出代價的 。

So, how do we come out of this impasse?

那么，我們如何擺脫這種僵局呢？

The most effective way to get something done is doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of reducing the costs now. It’s easy to say, but so hard to do!

完成某件事的最有效方法是盡可能自然地完成它。 人的本性是懶惰的(這里的軟件開發人員是表現最好的人)和貪婪的人，所以您現在必須找到降低成本的方法 。 這很容易說，但是很難做到！

Here I will share my experience and what has worked for me in turning the benefit/cost ratio to my favour.

在這里，我將分享我的經驗以及為我帶來利益/成本比率方面的成功經驗。

But before I do that, let’s analyze some typical difficulties in applying TDD.

但是在我這樣做之前，讓我們分析一下應用TDD的一些典型困難。

您可以測試兩個數字的和嗎？ (Are you able to test the sum of two numbers?)

Generally speaking, theory is not optional; you have to master it in order to master the practice. However trying to apply at once all the theoretical knowledge you’ve previously acquired could have the following effect:

一般來說，理論不是可選的。 您必須掌握它才能掌握練習。 但是，嘗試一次應用您先前已獲得的所有理論知識可能會產生以下效果：

The typical theory lesson on TDD starts with something like this:

關于TDD的典型理論課從以下內容開始：

And here you are like

在這里你就像

Then comes this:

然后是這樣的：

• red ? green ? refactor cycle
  紅色?綠色?重構周期
• unit, acceptance, regression, integration tests
  單元，驗收，回歸，集成測試
• mocking, stubs, fakes
  嘲笑，存根，假貨
• if you are lucky (or maybe unlucky ?), someone will tell you about contract testing
  如果您很幸運(或者可能很不幸？)，有人會告訴您有關合同測試的信息
• and if you are very lucky (or maybe very unlucky ?) you will touch legacy codebase refactoring
  如果您很幸運(或者可能很不幸？)，那么您將接觸到遺留的代碼庫重構。

The going gets tough, but you are an experienced developer and all these concepts are not that hard to handle for you. Then class ends; you go home, and throughout the next days you diligently do some code katas to fix the concepts just learned. So far so good.

事情變得艱難，但是您是一位經驗豐富的開發人員，所有這些概念對您來說都不難。 然后，課程結束； 您回家，然后在接下來的幾天里，您會認真地做一些代碼修改以修復剛剛學到的概念。 到目前為止，一切都很好。

掙扎是真的 (The struggle is real)

Next comes a real world project, with real deadlines and real timing costs — but you are motivated to apply your shiny new TDD. You start thinking about the architecture of your software and start writing tests for the first class and the class itself — let’s call it Class1.

接下來是一個具有真實期限和真實計時成本的現實世界項目，但是您有動力應用閃亮的新TDD。 您開始考慮軟件的體系結構，并開始為第一個類和類本身編寫測試-我們將其稱為Class1 。

Now you think about the first user of Class1, let’s call it UsageOfAClass, and again you test and write it. Class1 is a collaborator of UsageOfAClass, so are you going to mock it? Ok let’s mock it. But what about real interactions of Class1 and UsageOfAClass? Maybe you should test them all as well? Let’s do it.

現在，您考慮Class1的第一個用戶，我們稱它為UsageOfAClass，然后再次測試并編寫它。 Class1是UsageOfAClass的合作者，所以您要模擬它嗎？ 好吧，讓我們模擬一下。 但是，Class1和UsageOfAClass的真實交互又如何呢？ 也許您也應該對它們全部進行測試？ 我們開始做吧。

At this point, inside of you, you start hearing a little voice that says “I would develop much faster if I didn’t have to write these tests…”. You don’t listen to this evil voice and proceed straight to the next test.

在這一點上，你的內心，你開始聽到一點聲音，說：“ 我 會更快發展，如果我沒有寫這些測試...”。 您不會聽這種邪惡的聲音，而直接進行下一個測試。

Class2 is going to be used by UsageOfAClass and it persists itself inside a Db. So, do we have to test Class2, its interaction with UsageOfAClass, and the persistence in the Db? But wait… did anyone mention how to cope with I/O testing during the TDD theory class?

UseOfOfAClass將使用Class2 ，并將其自身保留在Db中。 那么，我們是否必須測試Class2，它與UsageOfAClass的交互以及在Db中的持久性？ 但是等等……有人在TDD理論課上有沒有提到如何應對I / O測試？

The theory behind TDD is not that hard to understand, but applying it to the real world can be really complex if you don’t approach it the right way.

TDD背后的理論并不難理解，但是如果您未采用正確的方法，將其應用于現實世界可能會非常復雜。

去做就對了 (Just do it)

We should always keep in mind that theory must be bent to our needs and not the contrary.

我們應該始終牢記，理論必須緊貼我們的需求，而不是相反。

The main goal is to get the job done. So my advice is, just do it!

主要目標是完成工作。 所以我的建議是， 隨便做吧 ！

Start simple and just do your task up to the end. Then, when you get stuck in some theoretical mind loop like:

從簡單開始，直到完成任務。 然后，當您陷入某些理論思維循環時，例如：

• is this a unit or an integration test?
  這是單元測試還是集成測試？
• here should I mock it or not?
  我應該在這里嘲笑嗎？
• oh crap, here I should write a new collaborator, so a brand new suite of infinite unit tests just to write “hey, banana”…
  糟糕，這里我應該寫一個新的協作者，因此，一套全新的無限單元測試套件只是寫了“嘿，香蕉”……

just forget about theory for a while and take a step forward. Just do it as it comes!

只是暫時忘記理論并向前邁進。 只要做到就行！

Once you are done with your task, have a look back at your work. Looking back at the completed job, it will be much easier to analyze what would have been the right thing to do.

完成任務后，請回顧一下您的工作。 回顧完成的工作，將更容易分析什么是正確的事情。

實用TDD (Practical TDD)

Just do it. By the way, I think this is also the right approach to TDD.

去做就對了。 順便說一句，我認為這也是解決TDD的正確方法。

What was wrong in how we built Class1, Class2 and UsageOfAClass? The approach.

我們如何構建Class1，Class2和UsageOfAClass出了什么問題？ 該方法。

This is a bottom-up approach:

這是一種自下而上的方法：

• analyze the problem
  分析問題
• figure out an architecture
  弄清楚一種架構
• start building it from unit components
  從單元組件開始構建

This approach is the best friend of over-engineering. You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is.

這種方法是過度工程的最好朋友。 通常，您構建系統是為了防止您認為將來會發生更改，而又不知道它們是否確實會更改。 然后，當某些需求發生變化時，無論它有多好，通常都會以不適合您的結構的方式發生。

For me the key to drastically reducing the immediate cost of writing with TDD has been to take a top-down approach:

對我而言，大幅降低使用TDD進行寫作的即時成本的關鍵在于采取自上而下的方法：

bring a user story

帶來用戶故事

write a very simple test of a use case

編寫一個非常簡單的用例測試

make it run

使它運行

go back to step 2 until all use cases are complete

返回第2步，直到所有用例都完成為止

While doing this process, don’t worry too much about architecture, clean code (well, remember at least to use decent variables names) or any kind of complication that is not currently needed. Just do what you know you need now, up to the end.

在執行此過程時，不必過分擔心體系結構，干凈的代碼(至少要記住使用體面的變量名)或當前不需要的任何復雜形式。 盡一切所能 ，直到最后。

Tests of the story clearly state what are the current and known requirements.

對故事的測試清楚地說明了當前和已知的要求。

Once you are done, take a look at your big ball of spaghetti mud code, get over the shame, and look deeper at what you have done:

完成后，看看您的意大利面條泥代碼大團子，擺脫羞恥，然后更深入地了解已完成的工作：

• it works! And tests prove it.
  有用！ 測試證明了這一點。

• All the system is there, and just what is actually needed to get the job done.

  所有的系統都在那里， 而完成工作實際上需要什么 。

Now you have an overview of all the parts of your system, so you can refactor with the knowledge of the domain that you couldn’t have had when you started from scratch. And tests will make sure that nothing will break while refactoring.

現在，您已經了解了系統的所有部分，因此您可以借助從頭開始時沒有的域知識來進行重構。 并且測試將確保重構時不會破壞任何內容。

重構 (Refactoring)

The best way for me to start to refactor is to identify areas of responsibility and separate them in private methods. This step helps identify responsibilities and their inputs and outputs.

對我而言，重構的最佳方法是確定責任范圍，并以私人方式將其分開。 此步驟有助于確定職責及其輸入和輸出。

After that, classes of collaborators are almost there and you just need to move them into different files.

在那之后，協作者的類別幾乎已經存在，您只需要將它們移到不同的文件中即可。

As you proceed, first write tests for the classes that pop out from the process and iterate until you are satisfied with the result. And remember, if you get stuck somewhere, just do it! If you do something bad, once you are done you will have more information on how to get over the mistake the next time you face it. Getting the job done is the priority, to the best of your current abilities.

在繼續過程中，首先為從過程中彈出并迭代的類編寫測試，直到對結果滿意為止。 記住，如果您被卡在某個地方，那就去做吧！ 如果您做的不好，一旦完成，您將獲得有關如何在下次遇到錯誤時克服錯誤的更多信息。 盡您最大的能力， 將工作做好是優先事項 。

This way, if you analyze your errors to learn from them, you will also refine your abilities.

這樣，如果您分析錯誤以從中學習，您還將提高自己的能力。

下一個用戶故事 (The next user story)

Continue developing your product following these steps:

請按照以下步驟繼續開發產品：

• take a story
  講一個故事
• make it work completely in a “test — code” cycle.
  使其完全在“測試-代碼”循環中工作。
• refactor
  重構

While adding features you will continue to change your software and maybe even its structure. But as the system grows, the cost of change will maintain a linear growth thanks to the two main features of TDD:

添加功能時，您將繼續更改軟件，甚至可能更改其結構。 但是隨著系統的發展，由于TDD的兩個主要功能，變更成本將保持線性增長：

• architecture discovery (that helps to control the complexity)
  架構發現(有助于控制復雜性)
• protection from breaking changes
  保護免受重大更改

The system will not be over-engineered, as architecture is going to emerge as stories get completed. You don’t think about what could be future requirements; if you end up needing it, then the cost to implement it will be low.

該系統不會進行過度工程設計，因為隨著故事的完成，架構將會出現。 您沒有考慮將來的需求； 如果最終需要它，則實施它的成本將很低。

有什么可能使它出錯？ (What can make it go wrong?)

The size of the story. What you build up to the end must be the right size. Not too big (otherwise it will take too much time to get any feedback) or too small (otherwise you won’t have the overview).

故事的大小。 最終構建的內容必須是正確的大小。 不太大(否則將花費太多時間來獲得任何反饋)或太小(否則將沒有概述)。

What if the story is too big? Split it up in pieces that can be built from the start to the end.

如果故事太大了怎么辦？ 將其拆分為可以從頭到尾構建的部分。

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

In the next article I will give a practical example of the concepts I explained here. We will implement, step by step, the Bowling Game kata starting from an acceptance test.

在下一篇文章中，我將給出在此說明的概念的實際示例。 我們將從驗收測試開始逐步實施保齡球游戲kata 。

It is not a real world problem, but it has enough complexity to see how TDD can help in handling it.

這不是一個現實世界的問題，但是它具有足夠的復雜性，可以了解TDD如何幫助處理它。

Please share your opinion and suggestions about this article. Do you agree with me or do you think that all this is a bunch of rubbish? Let me know what you think in comments; it would be very nice to start a conversation on TDD and share our experiences.

請分享您對本文的看法和建議。 您是否同意我的觀點，或者您認為這都是一堆垃圾？ 讓我知道您在評論中的想法； 最好在TDD上進行對話并分享我們的經驗。

I want to thank Matteo Baglini for helping me to find my way through a practical approach to software development and TDD.

我要感謝Matteo Baglini幫助我通過一種實用的軟件開發和TDD方法找到了自己的出路。

Thank you for reading!

感謝您的閱讀！

Cover image courtesy of testsigma.

封面圖片由testigma提供 。

翻譯自: https://www.freecodecamp.org/news/practical-tdd-test-driven-development-84a32044ed0b/

tdd測試驅動開發課程介紹

總結

以上是生活随笔為你收集整理的tdd测试驱动开发课程介绍_测试驱动开发的实用介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

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