91夜夜夜精品一区二区,91视频APP污污污下载,亚洲性无码av在线dvd

為什么要測試，測試是如何令人更快樂的？（一）

來源：教育聯(lián)展網(wǎng) ｜發(fā)布時(shí)間：｜編輯：佚名

來源：51Testing軟件測試網(wǎng)

我曾經(jīng)是一個(gè)不測試主義者，因?yàn)槲铱床坏綔y試的價(jià)值。然后，我試了一段時(shí)間，變得對它深信不疑。我收集了一些經(jīng)驗(yàn)，當(dāng)然還遠(yuǎn)遠(yuǎn)不夠。這篇文章總結(jié)了一些我知道的以及我認(rèn)為我知道的內(nèi)容。
“我不總測試我的代碼，但是當(dāng)我測試的時(shí)候，感覺更好?！?/span>—— 我
這是怎么一回事呢？
  這，全是因?yàn)榇a：
本文主要關(guān)于單元測試，而不是集成測試或端至端的測試，但在某些方面也可用于其他測試。在實(shí)踐中，測試很少是單一的或非此即彼的，并且這也不是目的。
  單元測試成本低廉，因此應(yīng)該成為測試工作中極大的組成部分。編寫和運(yùn)行單元測試都很便宜。因?yàn)樗徊榭创a的特定部分。集成測試則相反，它們包含的代碼更大。
為什么這很重要？
  測試可幫助你對你的代碼放心。對一個(gè)稍復(fù)雜的問題寫一個(gè)解決方案，然后手動(dòng)測試，你只需要這么做就可以了。有著一定經(jīng)驗(yàn)的你當(dāng)然可以自信地發(fā)布代碼，但是結(jié)果卻往往是拋棄了發(fā)現(xiàn)錯(cuò)誤的首次機(jī)會。
  測試能讓你體驗(yàn)?zāi)愕拇a中在極端的條件下是什么樣的。要是傳遞的數(shù)字是負(fù)數(shù)，會怎么樣，在我們總是假定數(shù)值為正的情況下？要是傳遞的根本就不是數(shù)字，會怎么樣？
“每個(gè)人都會寫出 bug，我們都寫過 bug。因此，這不是“你能正確地編寫代碼或一次性寫出正確代碼？”的問題，我們都寫過不正確的代碼。這就是我們所做的一切，我們寫的都是不正確的代碼。”——Joe Eames《JavaScript. Air 004》
編碼是辛苦，我們都應(yīng)該承認(rèn)這一點(diǎn)。其中的主要原因之一就是，你需要測試代碼，以獲得它能如期表現(xiàn)的信心，不管是什么代碼。
  不相信？這里給出了一些附加參數(shù)：
測試過的代碼更好
  許多人會告訴你，代碼測試會導(dǎo)致更好的代碼質(zhì)量。這在使用單元測試，并且至少在測試驅(qū)動(dòng)開發(fā)上有所行動(dòng)，即使這些行動(dòng)甚為草率時(shí)，尤其如此。原因如下：
  如果你的代碼難以測試，那么可能是你代碼沒有寫好。好代碼的定義是什么，這是一個(gè)大問題，但這里要強(qiáng)調(diào)的一句話是一個(gè)很好的經(jīng)驗(yàn)法則，也是大多數(shù)人所贊同的，那就是，好的代碼會分離關(guān)注點(diǎn)。有經(jīng)驗(yàn)的程序員限制功能體以便于只做一件邏輯上的事情就是這個(gè)原因。
  目標(biāo)對齊
  代碼很難測試可能要么是因?yàn)橛刑嗟氖虑橐^續(xù)，要么是因?yàn)橛刑嗟囊蕾嚕ɑ騼烧呓杂校?。考慮將此視為協(xié)調(diào)利益的一個(gè)問題：在編寫未經(jīng)測試的代碼時(shí)，在速度（或懶惰）和關(guān)注點(diǎn)分離之間存在著利益沖突，并且短期內(nèi)你的代碼是如何被組織的并沒有那么重要。當(dāng)代碼必須測試時(shí)，你的目標(biāo)更一致，因?yàn)閷τ趯懙煤玫拇a，更易于寫測試！
  像消費(fèi)者一樣思考
  當(dāng)你首次編寫測試時(shí)，你首先要設(shè)計(jì)代碼的 API。測試讓你進(jìn)入代碼消費(fèi)模式，在這種模式下，你的代碼需要面對其他東西的接口。設(shè)計(jì) API，而不那么關(guān)注內(nèi)部運(yùn)作將導(dǎo)致一個(gè)更佳的 API 設(shè)計(jì)，這會導(dǎo)致模塊的更易消耗，從而促進(jìn)項(xiàng)目代碼的更干凈。
  靈感突現(xiàn)
  測試會讓你靈機(jī)一現(xiàn)。通常情況下，因?yàn)樗仁鼓闳ニ伎歼吘壡闆r——零值，10 ^ 12，null 或 undefined。這使得你有機(jī)會來思考。去反省，以及了解在陌生的環(huán)境下會發(fā)生什么。僅僅是思考這些的過程，或代碼將面對的其他情況，都經(jīng)常會讓你意識到代碼可以簡化（以及代碼需要如何保護(hù)自我）。
  這些靈感突現(xiàn)的時(shí)刻也可能來自特別令人沮喪的情況之一：當(dāng)你的代碼和測試不一致的時(shí)候。你正處于不知道哪個(gè)才正確的兩難境地。如果你碰到這種情況，那么設(shè)計(jì)可能有問題，或者你的前提假設(shè)發(fā)生了變化。把它看成是一個(gè)好兆頭！你的代碼將會更滿意。
  測試可以說明代碼做了什么
  沒有人喜歡寫文檔，但當(dāng)你繼承（從一年前的自己，或其他人）或接口的模塊文檔齊全的時(shí)候，絕對是好的。測試可以成為這樣一種途徑，并且還有一個(gè)額外的好處是：測試用實(shí)際行動(dòng)證實(shí)代碼。就如同極佳的科學(xué)教師，他們不只是用嘴巴告訴你，氫氣易燃，而是充了一個(gè)氫氣球，讓它升到天花板上，然后在棍子上放一根點(diǎn)燃的火柴靠近氣球（這是我五年級時(shí)特別難忘的時(shí)刻之一）。
  你知道所有 bug 的共同點(diǎn)嗎？那就是它們經(jīng)過了所有的測試。所以，當(dāng)你找到一個(gè) bug 的時(shí)候，就等于知道測試哪里還需要改進(jìn)。
  測試可以使得更容易地加入項(xiàng)目，因?yàn)樗鼈兘沂玖舜a實(shí)際上應(yīng)該做什么。它們告訴你設(shè)計(jì)決策，以及初始的開發(fā)人員心里在想什么。
  不要擔(dān)心，去重構(gòu)吧
  也曾看到過烏七八糟的代碼，但不敢去清理干凈？我在這種情況下要做的首件事是創(chuàng)建測試來找出代碼要做什么。測試可以鎖定功能，用一種很好的方式，使得我們能夠?qū)Ｗ⒂凇按髵叱保皇菗?dān)心破壞什么東西。
  我見過一些糟糕到讓人不知道它們是做什么的代碼片段。同樣的，人人避之唯恐不及，不但要擔(dān)心會破壞預(yù)期的功能，而且還要擔(dān)心破壞 bug。我認(rèn)為基于過去的I/ O 的大型測試集是非常值得的投資。
  有趣的是，擔(dān)心和快樂的心情是成反比的。總之是一種此消彼長的狀態(tài)。
  自信地創(chuàng)造價(jià)值和正確的產(chǎn)品
  正確的代碼比不正確的代碼更有價(jià)值。一切幫助你的代碼比以前更正確的東西都值得看一看，就這么簡單。發(fā)布正確的代碼隨著時(shí)間的推移會構(gòu)建起信任，而信任是一筆寶貴的財(cái)富。
  魚與熊掌不可得兼
  這里有一個(gè)技巧：不要在試圖解決問題的同時(shí)，設(shè)計(jì)一個(gè)很好的解決方案。來自于 Ian Cooper 關(guān)于 TDD 演講中的秘訣是：
  編寫紅色測試。解個(gè)問題，盡快讓它變綠。設(shè)計(jì)一個(gè)很好的解決方案，重構(gòu)成你為之驕傲的一個(gè)東西。
  這里要掌握的一個(gè)重要內(nèi)容是，在你的大腦中要分離關(guān)注點(diǎn)。不要試圖同時(shí)完成步驟 2 和步驟3。編程的主要限制之一是你的大腦一次能思考多少，并且在你敲代碼時(shí)，你需要思考得越少，你寫的代碼越好。
  在解決問題時(shí)，不要去想代碼實(shí)際上應(yīng)該如何。復(fù)制粘貼代碼，寫低效的循環(huán)，重復(fù)內(nèi)容，不論是什么只要能盡快讓測試變綠就去做。然后再考慮如何改進(jìn)。
  分離關(guān)注點(diǎn)是首先要測試的原因之一，這種方法有助于實(shí)踐中行為。當(dāng)你不擇手段地想要快速達(dá)成一個(gè)解決方案時(shí)，你不必去考慮它看上去怎么樣或者運(yùn)行起來快不快。當(dāng)你進(jìn)行到完善設(shè)計(jì)和改善解決方案的時(shí)候，你就不必?fù)?dān)心解決方法行不通了。