Blog
0

TDD: Write Many Tests Together? Or One At A Time?

  • Pradyumn Sharma
  • May 9, 2017

Tags: ,

One question that I am often asked during my training programs on Agile Software Development, as well in consulting assignments, is the following:

While applying TDD (Test-Driven Development), which of the following two approaches should one use?

  • Identify and write (automate) as many test cases as you can, before writing the code to make the tests pass.
  • Or, begin with writing just one test case, and then writing the code to make it pass. And then add one more test case, and make that pass too. Repeat this until you can no longer think of any other test cases.

My short answer is: Choose whatever works well for you; personally I prefer to write many test cases at once (the first approach) more often than write one test case at a time (the second approach).

And now for a more detailed explanation. The “purists” almost always recommend the second approach: write one test; make it pass; write another test; make it pass by refactoring; repeat.

For people who are new to TDD, it may be more comfortable to take one step at a time. Like when we learn any new programming language, we start with the minimal first steps, often by writing a “Hello, World” program.

But as you gain confidence with a programming language and get ready to solve larger, more complex problems, you no longer need to write a program in tiny baby steps. You take bigger strides, you cover increasing more ground in one go.

This manner of thinking applies to TDD tasks as well. When you are new to TDD, it is a good idea to take baby steps, one at a time. But as you become more proficient, you can confidently identify and write multiple tests in one go that specify how your class or component will behave as a whole. You may still choose to implement your class or component to make the tests pass one at a time, without any risk.

Automated tests are a great way to ferret out the requirements and be explicit about them. When I have to implement some behavior in a class, I find it more efficient to think about all the expectations from the class (even if I’ll implement that behavior one at a time), so that I get a full picture of what a class is supposed to do.

Writing one test case at a time, usually makes me feel uncomfortable that I may miss some scenarios as I move forward. I worry that I may remain too engaged in the small details to consider the big picture. At the same time, I cannot claim that I will be able to identify all the required test cases upfront. And that is fine too. I do my best to think of as many scenarios as possible before starting the implementation. As I start implementing the class, additional scenarios often occur to me, and I keep adding those to the test cases.

Let’s consider an example, even if it appears to be a simple, academic algorithm problem. Suppose I am implementing a Stack class.

I would first ask myself this question: what is expected of a stack? The ability to add an element to it (push), remove the topmost object (pop), find out the number of elements in it (size), and perhaps examine the topmost object without removing it (peek).

Rather than think about just one test for the Stack class, I would now exercise my mind to write down as many possibilities as I can, such as:

  • A new stack should be empty (size == 0)
  • A push() operation should increase the size of the stack by one.
  • A pushed element should be at the top of the stack
  • A pop() operation should remove the topmost object and return its value to the client, and reduce the size by one
  • But pop() on an empty stack should throw an exception
  • Successive pop() operations should remove and return the elements from a Stack in the reverse order (until the stack becomes empty)
  • A peek() operation should return a reference to the topmost element without removing it from the stack, and thereby the size should remain unchanged
  • … (and so on)

I feel reasonably comfortable with this approach, despite knowing that some scenarios may not have occurred to me yet. On the other hand, identifying only test case at a time would leave me with a nagging fear that I may not be seeing the big picture, and I may fail to even think of some important scenarios later.

Once I have the list of the scenarios that I can think of, then I write all the test methods in my test class. As I write the test code, and the compiler complains about the missing push(), pop(), peek(), etc methods, I let the IDE generate those methods for me, but I don’t bother with the implementation yet.

After all the test methods (that I could initially think of) are written by me, then, naturally, I turn my attention to implementing the class that is being tested. Depending on my confidence, I may choose to implement the class one step at a time, or all of it, or something in between.

As an added advantage, the list of failing tests also serves the purpose of being a task list for me, as well as an indicator of progress. If 4 out of 10 test cases are passing at a time, it may be reasonable for me think that about 40% work on the class has been completed. This also helps me in making the estimate for the remaining effort for the class to complete. Though, of course, work completion and estimate of remaining effort can almost never be computed so precisely with a formula. But it certainly helps.


10 responses to “TDD: Write Many Tests Together? Or One At A Time?”

  1. click here says:

    Saved as a favorite, I really like your blog!

  2. I’d must examine with you here. Which isn’t something I normally do! I get pleasure from studying a put up that will make people think. Also, thanks for allowing me to comment!

  3. SUISSE PROGRAMME 葆麗美 【白金抗皺活顏系列*】白金緩紋活顏輪廓緊實精華乳的商品介紹 UrCosme (@cosme TAIWAN) 商品資訊 SUISSE PROGRAMME 葆麗美,白金抗皺活顏系列*,白金緩紋活顏輪廓緊實精華乳

  4. Woah this particular website can be superb i love mastering your posts. Be in the excellent art! You currently know, many people feel the need around in this facts, you may make them enormously.. kumpulan youtube terbaik

  5. 全「身」趨勢!LSD真空無痛技術,無需使用冷凍啫喱,比傳統激光脫毛更安全,更舒適,更快捷。腿部背部永久脫毛,只需15分鐘!最快激光脫毛科技 配以22x35mm 及 9x9mm 治療機頭,比其他品牌之24mm為大,覆蓋肌膚範圍更廣。 因而更能縮短療程時間及次數。專為亞洲皮膚而設 因應不同膚色設定不同能量,無論膚色較深或較白均適用 最舒適及最有效的激光脫毛體驗 (與755nm及1064nm作比較) 設真空脫毛技術 LUMENIS LightSheer® Desire 激光脫毛儀備有真空脫毛技術,令激光能量更集中聚焦,達至更快及更有效之療程效果。

  6. IELLIOS是由歐盟資助倫敦大學細胞重建研究所研究. 採用諾貝爾生理醫學獎科技 , 透過”納米能量電流” 以最親膚與迅速導入的方式 , 利用電腦化系統去令皮膚再生 , 令皮膚組織在無創傷的情況下自然更新及收緊 . 這治療是無創無痛的 . 完成治療後亦沒有傷口 . 我們是香港第一引入IELLIOS的機構 , 醫生會根據客人不同情況去為你設計不同的組合 .在外國IELLIOS受到很多荷里活明星, 歌手以至政客的追棒 , Madonna的facialist kate somer -field就常用IELLIOS為她護理肌膚 , 令52歲的她肌膚輪廓均保持於30歲的狀態. IELLIOS的訊號技術,採用心臟起博起原理,活躍無法正常運作的心臟細胞。訊號技術可活化及修復愛損皮膚,透過傳送訊號,激活靜止的細胞。IELLIOS的訊號技術給予細胞指令,引發細胞再次生長,令肌膚重回年輕。

  7. TULIP HIFU療程屬非侵入性及非手術的緊膚修身治療,獲歐盟CE、韓國KFDA、GMP、ISO9001、ISO13485等認證,安全可靠。 Tulip的DUAL HIFU精細技術,對面部和眼部治療特別有效;另外,TULIP FB有的13mm及7mm STAMP蓋印式治HIFU治療頭設計,眼、面以外部位,同時具「造身」效果。TULIP【DUAL HIFU高能量聚焦超聲波平台】【特點】- 非手術、非侵入性緊膚治療- 適用於任何膚色肌膚- 治療更精確、更安全- 備有7mm及13mm治療頭,可收緊腹部、臀部、手臂等鬆弛肌膚 【治療目的】- 緊緻肌膚- 提升輪廓- 減淡皺紋- 重塑輪廓線條- 嫩膚亮肌- 提升下垂眼部- 重塑身體線條 (用於7mm/13mm修身治療頭)- 重點減少脂肪細胞 (用於7mm/13mm修身治療頭)

  8. 除皺特點 純度高,效果好 見效迅速,無創無痛 安全精準,表情自然 唯一在臨床有20多年的注射材料,全球超過11000000人使用 適用範圍 魚尾紋、額頭紋、眉間紋、鼻紋和頸部皺紋都可以祛除; 最適合於早期的、不太明顯的皺紋 不須使用任何的鎮靜劑或局部麻醉劑,且Botox除皺治療後可立即繼續進行正常的活動。 Botox除皺可以利用午休時間約診即可,完全不影響工作的安排。BOTOX肉毒桿菌素是一種高度純化的蛋白質,經過注射之後,能夠使導致動態皺紋的肌肉得到放鬆,它能夠阻斷導致肌肉收縮的神經細胞,使面部線條變得平滑並防止新皺紋形成。全球銷量第一品牌 在中國唯一獲得SFDA、FDA批准用於醫療美容的肉毒桿菌素 唯一一個擁有40年安全記錄的肉毒桿菌素 在70個國家獲得批准使用 BOTOX肉毒杆菌素

  9. 春節 says:

    韓國膠原蛋白提拉線,在韓國又稱作FTL(Fine Thread Lifting細線埋入拉提術)」,可達到最新趨勢V臉回春效果。它是運用獲得韓國食品藥品管理局KFDA最高安全等級認證的可吸收縫線PDO (polydioxanone)的Fine Thread(細螺紋) 埋入皮膚真皮層裡作用,利用異物反應原理,促進皮膚真皮膠原的增生、刺激局部微循環、從而提拉皮膚和肌肉,增強皮膚彈性,達到提升、除皺,美白、嫩膚等多重回春效果。

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2017 Pragati Software Pvt. Ltd. All Rights Reserved.

Enquiry