為什么測試喜歡ie

by Evelyn Chan

通過伊芙琳·陳

為什么我現(xiàn)在喜歡測試，以及為什么您也應(yīng)該如此。 (Why I now appreciate testing, and why you should, too.)

There’s a common misconception that writing tests slows down development speed. While the benefits of testing may not be immediately noticeable sometimes, it’s been my experience thus far that testing allows me to work faster in the long run, even on a small team.

有一個(gè)普遍的誤解，認(rèn)為編寫測試會(huì)降低開發(fā)速度。 盡管有時(shí)有時(shí)無法立即注意到測試的好處，但到目前為止，根據(jù)我的經(jīng)驗(yàn)，即使在一個(gè)小型團(tuán)隊(duì)中，測試也可以使我從長遠(yuǎn)來看可以更快地工作。

After implementing tests for a full-stack application, I’ve come to appreciate how useful it is to effectively test your apps and how it influences your coding ability.

在為全棧應(yīng)用程序?qū)嵤y試之后，我開始意識(shí)到有效測試應(yīng)用程序的有用性以及它如何影響您的編碼能力。

快速介紹一下測試堆棧的外觀 (Quick intro to what a test stack looks like)

Jest is a testing library developed by Facebook that comes prepackaged with a bunch of cool methods to make testing easier. On a recent project, my team and I chose Jest because of its ease of use and its wide range of built-in functions that help streamline your testing. It’s very simple to set up and uses the Expect library for assertions.

Jest是由Facebook開發(fā)的測試庫，它預(yù)包裝了許多很酷的方法，以簡化測試。 在最近的項(xiàng)目中，我和我的團(tuán)隊(duì)選擇了Jest，因?yàn)樗囊子眯院蛷V泛的內(nèi)置功能有助于簡化測試。 設(shè)置和使用Expect庫進(jìn)行斷言非常簡單。

Enzyme is the de-facto way of testing your React app. It’s pretty magical in that it renders your React components within Jest, allowing you to test your front end JSX code effectively without manually transpiling it. You render your components using one of three methods: shallow, mount, or render.

酶是測試您的React應(yīng)用程序的實(shí)際方法。 這非常神奇，因?yàn)樗贘est中呈現(xiàn)了您的React組件，使您無需手動(dòng)轉(zhuǎn)譯就可以有效地測試前端JSX代碼。 您可以使用以下三種方法之一來渲染組件：淺，安裝或渲染。

SuperTest allows you to make API calls without actually making the call, by intercepting it. API calls can be expensive and/or slow for unit tests, so you won’t want to make the call and wait for the response. Otherwise, it’ll slow down your tests and take forever to run.

SuperTest通過攔截來允許您進(jìn)行API調(diào)用而無需實(shí)際進(jìn)行調(diào)用。 API調(diào)用對于單元測試而言可能既昂貴又緩慢，因此您不希望進(jìn)行調(diào)用并等待響應(yīng)。 否則，它將減慢您的測試速度，并導(dǎo)致永遠(yuǎn)運(yùn)行。

這是我學(xué)到的 (Here’s what I’ve learned)

測試可防止回歸 (Testing prevents regression)

Adding new features frequently breaks existing code, and having tests can prevent this from happening. Testing helps ensure that your code works as you intend it to. As simple as it may sound, that makes a world of difference.

添加新功能經(jīng)常會(huì)破壞現(xiàn)有代碼，并且進(jìn)行測試可以防止這種情況的發(fā)生。 測試有助于確保您的代碼按預(yù)期工作。 聽起來似乎很簡單，但卻與眾不同。

It may seem silly to hear that not all programmers can articulate the code they write, but it’s actually pretty common. How many times have you been asked to explain something you wrote on the fly under a strict deadline and found yourself stuttering to answer? Writing tests forces you to think clearly about what exactly your function is taking in as an argument and returning as an output.

聽到并非所有程序員都能清楚地表達(dá)他們編寫的代碼，這似乎很愚蠢，但這實(shí)際上很常見。 在要求您嚴(yán)格解釋最后期限的情況下，有多少次您要解釋自己寫的東西，卻發(fā)現(xiàn)自己口吃不住？ 編寫測試會(huì)迫使您仔細(xì)考慮您的函數(shù)究竟將什么作為參數(shù)并作為輸出返回。

Even if you do understand the purpose of each line of code, as time goes on, you’ll inevitably start to forget. Tests provide an important complement to documentation that helps you move back and forth between code bases quickly. Taking the time to write good, efficient tests allows you to refactor your code much more easily and develop with confidence.

即使您確實(shí)了解每一行代碼的目的，隨著時(shí)間的流逝，您也不可避免地會(huì)忘記。 測試是對文檔的重要補(bǔ)充，可幫助您快速在代碼庫之間來回移動(dòng)。 花時(shí)間編寫良好，高效的測試可以使您更輕松地重構(gòu)代碼并充滿信心地進(jìn)行開發(fā)。

使用模擬和存根進(jìn)行單元測試。 (Unit test with mocks and stubs.)

In a unit test, you test a specific piece of code one at a time. In any application, your code probably will make calls to and depend on other classes or modules. As these relationships between classes increase in complexity, it’ll obfuscate the source of bugs.

在單元測試中，您一次測試一個(gè)特定的代碼段。 在任何應(yīng)用程序中，您的代碼可能都會(huì)調(diào)用并依賴于其他類或模塊。 隨著類之間的這些關(guān)系增加復(fù)雜性，它將掩蓋錯(cuò)誤的來源。

In order to isolate and debug effectively, you can replace these dependencies with a mock or a stub to control the behavior or output you expect.

為了有效地隔離和調(diào)試，可以使用模擬或存根替換這些依賴關(guān)系，以控制所需的行為或輸出。

For example, let’s say you want to test the following method:

例如，假設(shè)您要測試以下方法：

import database from 'Database';import cache from 'Cache';const getData = (request) => { if (cache.check(request.id)) { // check if data exists in cache return cache.get(request.id); // get from cache } return database.get(request.id); // get from database};

Stub:

存根：

test('should get from cache on cache miss', (done) => { const request = { id: 10 }; cache.check = jest.fn(() => false);getData(request); expect(database.get).toHaveBeenCalledWith(request.id); done();});

Mock:

嘲笑：

test('should check cache and return database data if cache data is not there', (done) => { let request = { id: 10 }; let dummyData = { id: 10, name: 'Foo' } let cache = jest.mock('Cache'); let database = jest.mock('Database'); cache.check = jest.fn(() => false); database.get = jest.fn(() => dummyData);expect(getData(request)).toBe(dummyData); expect(cache.check).toHaveBeenCalledWith(request.id); expect(database.get).toHaveBeenCalledWith(request.id); done();});

The main difference between the two lies in state vs behavioral manipulation.

兩者之間的主要區(qū)別在于狀態(tài)與行為操縱。

When using mocks, you replace the entire module with a mock object. A stub is a forced output of a function no matter the given input. Mocks are used to test if a function is being called with the right arguments, and stubs are used to test how a function operates on a given response. Stubs are used to validate the state of a method, whereas mocks are used to evaluate the behavior.

使用模擬時(shí)，可以用模擬對象替換整個(gè)模塊。 無論給定輸入如何，樁都是函數(shù)的強(qiáng)制輸出。 模擬用于測試是否使用正確的參數(shù)調(diào)用了函數(shù)，而存根用于測試函數(shù)如何在給定的響應(yīng)下運(yùn)行。 存根用于驗(yàn)證方法的狀態(tài)，而模擬用于評估行為。

Jest provides jest.fn, which has both basic mocking and stubbing functionality. A Jest mock can also stub method outputs, and in this case be both a mock and a stub.

Jest提供了jest.fn ，它具有基本的jest.fn和存根功能。 Jest模擬還可以對方法輸出進(jìn)行存根處理，在這種情況下，它既可以是模擬也可以是存根。

The concept of mocks in testing and how they differ from stubs can get pretty complex, so for a deeper dive, check out the links at the end!

測試中的模擬概念以及它們與存根的區(qū)別會(huì)變得非常復(fù)雜，因此，如果要進(jìn)行更深入的研究，請查看最后的鏈接！

知道您不需要測試的內(nèi)容。 (Know what you don’t need to test.)

You’ll want to test every method you write. But keep in mind that depending on your code base, 100% test coverage is unlikely and most times not even necessary.

您將要測試您編寫的每種方法。 但是請記住，根據(jù)您的代碼庫，不可能100％覆蓋測試，大多數(shù)情況下甚至沒有必要。

With Jest, you can easily track your test coverage by adding a--coverage tag to your test script on your CLI. While this is a useful measure, take this with a grain of salt — the way Jest measures test coverage is through tracing the call stack, so a higher test coverage doesn’t necessarily mean your tests are effective.

使用Jest，您可以在CLI的測試腳本中添加--coverage標(biāo)記，從而輕松跟蹤測試范圍。 盡管這是一個(gè)有用的措施，但要花一點(diǎn)點(diǎn)時(shí)間-Jest衡量測試覆蓋率的方法是通過跟蹤調(diào)用堆棧，因此更高的測試覆蓋率并不一定意味著您的測試有效。

For example, in a previous project, I used a library to implement a carousel component. Within the component was a function to render a list based on an array. To increase test coverage, I wrote a test to count and compare the number of rendered items to the array. The carousel component modified the number of items being rendered on the DOM to be more than a 1:1 output, even though the implementation visually displayed the correct number of elements in the browser. I chose to forego the test coverage because it was essentially testing the carousel library instead of my code.

例如，在上一個(gè)項(xiàng)目中，我使用一個(gè)庫來實(shí)現(xiàn)輪播組件。 組件內(nèi)有一個(gè)基于數(shù)組呈現(xiàn)列表的函數(shù)。 為了增加測試覆蓋率，我編寫了一個(gè)測試以計(jì)算并比較渲染項(xiàng)目到數(shù)組的數(shù)量。 輪播組件將DOM上呈現(xiàn)的項(xiàng)目數(shù)修改為大于1：1的輸出，即使該實(shí)現(xiàn)在瀏覽器中直觀地顯示了正確數(shù)量的元素。 我選擇放棄測試范圍，因?yàn)樗鼘?shí)際上是在測試輪播庫而不是我的代碼。

Let’s assume a Listings component with a method renderCarousel that renders a carousel from an external library:

讓我們假設(shè)一個(gè)Listings組件帶有一個(gè)renderCarousel方法，該方法從外部庫中呈現(xiàn)一個(gè)輪播：

Ineffective test:

測試無效：

test('should return the same number of elements as the array', (done) => { // Full DOM render let mountWrapper = mount(<Listings />);// State change to trigger re-render mountWrapper.instance().setState({ listings: [listing, listing, listing] });// Updates the wrapper based on new state mountWrapper.update();expect(mountWrapper.find('li').length).toBe(3); done(); })

Effective test:

有效測試：

test('should call renderCarousel method when state is updated', (done) => { // Mock function inside component to track calls wrapper.instance().renderCarousel = jest.fn();// State change to trigger re-render wrapper.instance().setState({ listings: [listing, listing, listing] });expect(wrapper.instance().renderCarousel).toHaveBeenCalled(); done(); });

The difference between the two lies in what the tests are actually testing.

兩者之間的區(qū)別在于測試實(shí)際測試的內(nèi)容。

The first example evaluates the renderCarousel function, which calls the external library. The second test evaluates whether the renderCarousel is simply being called. Since the external libraries are somewhat akin to a black box of magic and are being tested by their own developers, it’s not necessary to write a test that makes sure it’s working correctly.

第一個(gè)示例評估renderCarousel函數(shù)，該函數(shù)調(diào)用外部庫。 第二個(gè)測試評估是否只是簡單地調(diào)用renderCarousel。 由于外部庫有點(diǎn)類似于魔術(shù)的黑盒子，并且正在由其自己的開發(fā)人員進(jìn)行測試，因此無需編寫確保其正常工作的測試。

In this scenario, we only need to test that the library is being called and have faith that the library’s developers are handling the testing.

在這種情況下，我們只需要測試正在調(diào)用該庫，并確信該庫的開發(fā)人員正在處理測試。

Understanding what you do and don’t need to test lets you maximize your time to remove redundancies.

了解您要做的事情和不需要進(jìn)行的測試，可以使您最大限度地利用時(shí)間來消除冗余。

精心設(shè)計(jì)的測試會(huì)導(dǎo)致精心設(shè)計(jì)的代碼。 (Well-designed tests lead to well-designed code.)

Designing your code knowing you’ll have to write tests for it improves your code. This is known as test-driven development, which is supported by a wide margin of the coding community.

在設(shè)計(jì)代碼時(shí)就知道您必須為此編寫測試，從而可以改善代碼。 這就是所謂的測試驅(qū)動(dòng)開發(fā)，它得到了編碼社區(qū)的廣泛支持。

In order to appropriately unit test functions, you need to strip away logic and test one method at a time. This structure forces you to write modular code and abstract logic away from your components.

為了適當(dāng)?shù)貙y試功能進(jìn)行單元化，您需要?jiǎng)冸x邏輯并一次測試一種方法。 這種結(jié)構(gòu)迫使您編寫遠(yuǎn)離組件的模塊化代碼和抽象邏輯。

As you think about your code in terms of writing tests, you’ll start to develop the habit of decoupling your code. I’ve discovered that writing your code this way seems to produce a story-like structure that’s both easier to write and easier to follow.

在考慮編寫測試代碼時(shí)，您將開始養(yǎng)成將代碼分離的習(xí)慣。 我發(fā)現(xiàn)以這種方式編寫代碼似乎產(chǎn)生了一個(gè)類似故事的結(jié)構(gòu)，既易于編寫，又易于遵循。

Let’s consider a scenario where we’re calling an endpoint to fetch data from a database and formatting that data before we return it.

讓我們考慮一個(gè)場景，在該場景中，我們調(diào)用端點(diǎn)從數(shù)據(jù)庫中獲取數(shù)據(jù)并在返回?cái)?shù)據(jù)之前對其進(jìn)行格式化。

Too much logic:

邏輯太多：

// Define endpointapp.get('/project', (request, response) => { let { id } = request.params; let query = `SELECT * FROM database WHERE id = ${id}`; database.query(query) .then((result) => { const results = []; for (let index = 0; index < data.length; index++) { let result = {}; result.newKey = data[index].oldKey; results.push(result); } response.send(results); }) .catch((error) => { response.send(error); }) })

Easier to test:

更容易測試：

// Make call to database for dataconst getData = (request) => { return new Promise((resolve, reject) => { let { id } = request.params; let query = `SELECT * FROM database WHERE id = ${id}`; database.query(query) .then(results => resolve(results)) .catch(error => reject(error)); };}// Format data to send backconst formatData = (data) => { const results = []; for (let index = 0; index < data.length; index++) { let result = {}; result.newKey = data[index].oldKey; results.push(result); } return results;}// Send back dataconst handleRequest = (request, response) => { getData(request) .then((result) => { let formattedResults = formatData(result) response.send(formattedResults); .catch((error) => { response.send(error);}// Define endpointapp.get('/project', handleRequest);

While the second example is longer, it’s much easier to follow along. The logic is clearly abstracted and isolated, making it much easier to test.

盡管第二個(gè)示例更長，但更容易理解。 邏輯被清楚地抽象和隔離，使其更容易測試。

If you’re just starting out with testing/coding, it can be hard to discern what makes a well-designed test. You can’t write effective tests if your code isn’t designed well, but you can’t figure out what makes code suitable for the tests you can’t write! Fortunately, this leads to my last tip…

如果您只是從測試/編碼開始，那么很難分辨出什么是設(shè)計(jì)良好的測試。 如果您的代碼設(shè)計(jì)不當(dāng)，您將無法編寫有效的測試，但是您無法弄清楚是什么使代碼適合您無法編寫的測試！ 幸運(yùn)的是，這引出了我的最后一條提示……

在編寫代碼時(shí)編寫測試 (Write tests as you code)

The best way to incorporate testing is to write it alongside your code. Otherwise, it’ll feel overwhelming when you write them all at once and have to go back and forth between all your test and method files.

合并測試的最佳方法是將其與代碼一起編寫。 否則，當(dāng)您一次全部編寫它們并且不得不在所有測試文件和方法文件之間來回切換時(shí)，會(huì)感到不知所措。

Many beginners make the mistake of treating tests as something you do after all your code is written. If you treat it as a task you do alongside your code, it not only improves your code but also makes writing them more achievable.

在編寫所有代碼之后，許多初學(xué)者會(huì)犯錯(cuò)誤，將測試視為您要做的事情。 如果您將其視為與代碼一起執(zhí)行的任務(wù)，那么它不僅可以改善代碼，還可以更輕松地編寫代碼。

In a system with cleanly abstracted APIs, you can test each class before moving on so you know which part of the logic is broken. For instance, my ‘get’ endpoint calls getData to interact with the database. I would write tests for getData first and make sure those are green. That way, I know that if any of my controller tests fail, it probably has to do with the way I’m calling getData.

在具有干凈抽象的API的系統(tǒng)中，您可以在繼續(xù)進(jìn)行之前測試每個(gè)類，以便知道邏輯的哪一部分壞了。 例如，我的“ get”端點(diǎn)調(diào)用getData與數(shù)據(jù)庫進(jìn)行交互。 我會(huì)先為getData編寫測試，并確保它們是綠色的。 這樣，我知道如果我的任何控制器測試失敗，則可能與我調(diào)用getData的方式有關(guān)。

Hopefully this write-up has helped you understand why testing is so useful and has equipped you with some tips on how to get started. This only hits the tip of the iceberg with testing, though! Here are some resources if you want to learn more:

希望這篇文章可以幫助您了解測試為什么如此有用，并為您提供了一些入門的技巧。 但是，這只是通過測試擊中了冰山一角！ 如果您想了解更多，這里有一些資源：

https://martinfowler.com/articles/mocksArentStubs.html

https://martinfowler.com/articles/mocksArentStubs.html

https://medium.com/@rickhanlonii/understanding-jest-mocks-f0046c68e53c

https://medium.com/@rickhanlonii/understanding-jest-mocks-f0046c68e53c

If you enjoyed this article, please click on the ?? and share to help others find it. Thanks for reading!

如果您喜歡這篇文章，請單擊??。 并分享以幫助他人找到它。 謝謝閱讀！

翻譯自: https://www.freecodecamp.org/news/why-i-now-appreciate-testing-and-why-you-should-too-74d48c67ab72/

為什么測試喜歡ie

總結(jié)

以上是生活随笔為你收集整理的为什么测试喜欢ie_为什么我现在喜欢测试，以及为什么您也应该如此。的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。