bdd cucumber

by Marko Anastasov

通過Marko Anastasov

如何使用BDD構(gòu)建堅如磐石的Ruby on Rails應(yīng)用 (How to build rock-solid Ruby on Rails apps with BDD)

了解通過行為驅(qū)動開發(fā)來構(gòu)建可持續(xù)Web應(yīng)用程序的最佳實(shí)踐。 (Learn best practices for building sustainable web apps with behavior-driven development.)

“Why do we fall sir? So that we can learn to pick ourselves up.”

“我們?yōu)槭裁匆蔀橄壬?#xff1f; 這樣我們就可以學(xué)會振作起來。 ”

I built my first Rails app ten years ago. I’ve tried all approaches, and if there’s one thing that I’m certain of, it’s that I can’t work without writing tests. And writing tests first is what has helped me advance my programming skills the most.

十年前，我構(gòu)建了我的第一個Rails應(yīng)用程序。 我已經(jīng)嘗試了所有方法，如果可以肯定的話，那就是沒有編寫測試我就無法工作。 首先編寫測試是幫助我最大程度地提高編程技能的原因。

It’s pretty simple. We want to feel and be as productive on day 1000 as we are on day 1 of the project. We want to be fast. For that we need clean code.

很簡單 我們希望在項(xiàng)目的第一天就感覺和在工作中一樣高效。 我們要快。 為此，我們需要干凈的代碼。

We can’t get everything right in the first pass, so we need to refactor. However, we can’t refactor under a constant fear that we’ll break stuff and ship bugs to production without knowing it. We need confidence that when we do break the code, we can detect and fix the issue right away.

我們不能在一開始就把所有事情都做好，所以我們需要重構(gòu)。 但是，我們不能一直擔(dān)心會在不知不覺中破壞東西并將錯誤運(yùn)送到生產(chǎn)環(huán)境中進(jìn)行重構(gòu)。 我們需要確信，當(dāng)我們確實(shí)破壞代碼時，我們可以立即檢測并解決問題。

Where does confidence come from? The automated test suite gives us confidence. Confidence that we can change, remove, or add new code, and no major problem will happen as long as our tests are passing.

信心從何而來？ 自動化測試套件使我們充滿信心。 我們可以更改，刪除或添加新代碼的信心，只要我們的測試通過，就不會發(fā)生重大問題。

So if tests are the foundation, let’s write them first. Do that for a while, and you’ll notice how clean and effective both your code and tests come out.

因此，如果測試是基礎(chǔ)，讓我們先編寫它們。 這樣做一會兒，您會注意到代碼和測試的效率和有效性。

了解“行為”觀點(diǎn) (Understanding the “behavior” point of view)

When applying test-driven development (TDD), developers can easily fall into the trap of using unit tests to test what an object or method is, rather than what it does, which is a lot more useful.

當(dāng)應(yīng)用測試驅(qū)動開發(fā)(TDD)，開發(fā)人員可以很容易地落入使用單元測試來測試的陷阱什么的對象或方法 ，而不是它做什么，這是很多更加有用。

An example would be writing a test which asserts that a collection of comments is specifically an array, and not one of its unique features, such as being sorted by time. In most cases, it shouldn’t matter if we change the implementation of that collection to return a custom enumerable class. More generally:

一個示例就是編寫一個測試，該測試斷言一個注釋集合專門是一個數(shù)組，而不是其唯一功能之一，例如按時間排序。 在大多數(shù)情況下，是否更改該集合的實(shí)現(xiàn)以返回自定義可枚舉的類無關(guān)緊要。 更普遍：

Changing the implementation of an object shouldn’t break its test suite, as long as what the object does remains the same.只要對象的行為保持不變，更改對象的實(shí)現(xiàn)就不應(yīng)破壞其測試套件。

Behavior-driven development (BDD) puts focus on behavior — what a thing does — on all levels of development.

行為驅(qū)動的開發(fā) (BDD)將注意力集中在所有級別的開發(fā)上的行為-一件事情做什么。

Initially, the word “behavior” may seem strange. Another way to frame this is to think about descriptions. We can describe every low-level method, object, button or screen to another person — and what we will be describing is exactly what a behavior is. Adopting this approach changes the way we approach writing code.

最初，“行為”一詞可能看起來很奇怪。 框架的另一種方式是考慮描述。 我們可以向另一個人描述每個低級方法，對象，按鈕或屏幕，而我們將要描述的正是行為。 采用這種方法會改變我們編寫代碼的方式。

“給定/何時/然后”通信模式 (The “Given / When / Then” communication pattern)

Most problems in software development are communication problems. For example, product manager fails to describe every use case of a proposed functionality. Developers misunderstand the scope of a feature. Product team doesn’t have a protocol to verify if a feature is done.

軟件開發(fā)中的大多數(shù)問題是通信問題。 例如，產(chǎn)品經(jīng)理無法描述所提議功能的每個用例。 開發(fā)人員誤解了功能的范圍。 產(chǎn)品團(tuán)隊(duì)沒有協(xié)議來驗(yàn)證功能是否已完成。

BDD simplifies the language we use to describe scenarios in which software should be used:

BDD簡化了用于描述應(yīng)使用軟件的方案的語言：

*Given* some context or state of the world,

*給出*一些背景或世界狀況，

*When* something happens,

* 當(dāng)*發(fā)生某些事情時，

*Then* we expect some outcome.

* 然后*我們期待一些結(jié)果。

Given, When, Then are simple words we can use to describe a complex feature, code object, or a single method equally well. It’s a pattern that all members of the team in various roles can understand.

給定“何時”，“然后”是簡單的單詞，我們可以很好地描述復(fù)雜的功能，代碼對象或單個方法。 所有角色的團(tuán)隊(duì)中的所有成員都可以理解這種模式。

These expressions are also built-in in many testing frameworks, such as Cucumber. A clear formulation of the problem and the solution that we need to implement helps us write better code.

這些表達(dá)式也內(nèi)置在許多測試框架中，例如Cucumber 。 對問題和解決方案的清晰表述有助于我們編寫更好的代碼。

Rails的BDD工具概述 (Overview of BDD tools for Rails)

Ruby on Rails was the first web framework to ship with an integrated testing framework. This acted as a springboard for further advancements of the craft.

Ruby on Rails是第一個帶有集成測試框架的Web框架。 這充當(dāng)了該技術(shù)進(jìn)一步發(fā)展的跳板。

At the same time, the expressiveness of Ruby and the productivity boost in developing web applications with Rails attracted many experienced and high-profile engineers to the community early on.

同時，Ruby的表現(xiàn)力和使用Rails開發(fā)Web應(yīng)用程序的工作效率提高，在早期就吸引了許多經(jīng)驗(yàn)豐富的知名工程師進(jìn)入社區(qū)。

When you generate a new Rails application with default options, it sets the scene for testing using test/unit, a testing library that comes with Ruby. However, there are tools which make BDD easier to apply. I recommend using RSpec as the main testing library and Cucumber for writing high-level acceptance tests.

當(dāng)您使用默認(rèn)選項(xiàng)生成一個新的Rails應(yīng)用程序時，它將使用Ruby附帶的測試庫test/unit設(shè)置要進(jìn)行測試的場景。 但是，有些工具使BDD易于應(yīng)用。 我建議使用RSpec作為主要測試庫，并建議使用Cucumber編寫高級驗(yàn)收測試。

規(guī)范 (RSpec)

RSpec is a popular BDD testing library for Ruby. Tests written using RSpec — called specs — are executable examples of expected behavior of a piece of code in a specified context. This is much easier to understand by reading the following code:

RSpec是一個流行的Ruby BDD測試庫。 使用RSpec編寫的測試(稱為規(guī)范 )是在指定上下文中一段代碼的預(yù)期行為的可執(zhí)行示例。 通過閱讀以下代碼，這將更容易理解：

describe ShoppingCart do context "when first created" do it "is empty" do shopping_cart = ShoppingCart.new expect(shopping_cart).to be_empty end endend

Well-written specs are easy to read, and as a result, understand. Try reading the code snippet above out loud. We are describing a shopping cart, saying that, given a blank context, when we create a new shopping cart, we expect(shopping_cart).to be_empty.

規(guī)范良好的規(guī)范易于閱讀，因此易于理解。 嘗試大聲閱讀上面的代碼片段。 我們正在描述一個購物車，說，給定空白上下文，當(dāng)我們創(chuàng)建一個新的購物expect(shopping_cart).to be_empty ，我們expect(shopping_cart).to be_empty 。

Running this spec produces output which resembles a specification:

運(yùn)行此規(guī)范將產(chǎn)生類似于規(guī)范的輸出：

ShoppingCart when first created is empty

We could use RSpec to specify an entire system, however we can also use a tool which helps us write and communicate even more naturally.

我們可以使用RSpec來指定整個系統(tǒng)，但是我們也可以使用一個工具來幫助我們更加自然地編寫和交流。

Cucumber (Cucumber)

As I explained in the first chapter of this guide, we want to test-drive the analysis phase of every new feature. To do that, we need customer acceptance tests to drive the development of the code which will actually implement the feature.

正如我在本指南第一章中所解釋的那樣，我們想測試每個新功能的分析階段。 為此，我們需要客戶驗(yàn)收測試來驅(qū)動將實(shí)際實(shí)現(xiàn)該功能的代碼的開發(fā)。

If you are a developer working in a sufficiently complex organization, you may want to have somebody else, like a customer or product, manager write acceptance tests for you (disclaimer: I’ve never worked in such environment). In most cases, the developer writes them. This is a good practice, because it helps us understand better what it is that we need to build. Cucumber provides the language and format to do that.

如果您是在足夠復(fù)雜的組織中工作的開發(fā)人員，則可能希望讓其他人(例如客戶或產(chǎn)品)，經(jīng)理為您編寫驗(yàn)收測試(免責(zé)聲明：我從未在這樣的環(huán)境中工作過)。 在大多數(shù)情況下，開發(fā)人員會編寫它們。 這是一個好習(xí)慣，因?yàn)樗梢詭椭覀兏玫亓私馕覀冃枰獦?gòu)建的內(nèi)容。 Cucumber提供了這樣做的語言和格式。

Cucumber reads plain text descriptions of application features, organized in scenarios. Each step in the scenario is implemented using concrete code, and it automates interaction with your application from the user’s standpoint. For example:

Cucumber讀取按場景組織的應(yīng)用程序功能的純文本描述。 該場景中的每個步驟都是使用具體代碼實(shí)現(xiàn)的，并且從用戶的角度來看，它可以自動與您的應(yīng)用程序進(jìn)行交互。 例如：

Feature: Reading articlesScenario: Commenting on an article Given I am logged in And I am reading an article with "2" comments When I reply to the last comment Then the article should have "3" comments And I should be subscribed to follow-up comments

If this were a web application, the scenario above could automatically boot a test instance of the application, open it a web browser, perform steps as any user would do, and then check if certain expectations have been met.

如果這是一個Web應(yīng)用程序，則上述方案可以自動啟動該應(yīng)用程序的測試實(shí)例，打開它的Web瀏覽器，像任何用戶一樣執(zhí)行步驟，然后檢查是否滿足某些期望。

Rails中的BDD周期 (The BDD cycle in Rails)

In practice, BDD implies an outside-in approach. We start with an acceptance test, then write code in the views, and work our way down to the models. This approach helps us discover any new objects or variables we may need to effectively implement our feature early on, and make the right design decisions based on this.

在實(shí)踐中，BDD意味著從外而內(nèi)的方法。 我們從驗(yàn)收測試開始，然后在視圖中編寫代碼，然后逐步進(jìn)行建模。 這種方法可幫助我們發(fā)現(xiàn)可能需要的任何新對象或變量，以盡早有效地實(shí)現(xiàn)我們的功能，并據(jù)此做出正確的設(shè)計決策。

The BDD cycle in Rails consists of the following steps:

Rails中的BDD周期包括以下步驟：

Start with a new Cucumber scenario. Before you write it, make sure to analyze and understand the problem. At this point you need to know how the user interface allows a user to do a job. Do not worry about the implementation of scenario steps.

從新的Cucumber方案開始 。 在編寫它之前，請確保分析并理解問題。 此時，您需要知道用戶界面如何允許用戶完成工作。 不必?fù)?dān)心方案步驟的實(shí)施。

Run the scenario and watch it fail. This will tell you which steps are failing, or pending implementation. At first, most of your steps will be pending (undefined).

運(yùn)行該方案并觀察它是否失敗 。 這將告訴您哪些步驟失敗或正在執(zhí)行。 首先，您的大多數(shù)步驟都將待處理(未定義)。

Write a definition of the first failing or pending spec. Run the scenario and watch it fail.

編寫第一個失敗或未決規(guī)范的定義 。 運(yùn)行方案并觀察它是否失敗。

Test-drive the implementation of a Rails view using the red-green-refactor cycle with RSpec. You’ll discover instance variables, controllers and controller actions that the view will need to do its job. This is also the only phase which has been proved to be optional in practice. An alternative approach is to simply prepare the views and controllers before moving on to the next step.

使用帶有RSpec的紅綠色重構(gòu)循環(huán)來測試Rails視圖的實(shí)現(xiàn) 。 您將發(fā)現(xiàn)視圖完成其工作所需的實(shí)例變量，控制器和控制器操作。 這也是實(shí)踐中被證明是可選的唯一階段。 另一種方法是簡單地準(zhǔn)備視圖和控制器，然后再進(jìn)行下一步。

Test-drive the controller using the red-green-refactor cycle with RSpec. Make sure that the instance variables are assigned and that the actions respond correctly. The controllers are typically driven with a mocking approach. With the controller taken care of, you will know what the models or your domain objects should do.

使用帶有RSpec的紅綠色重構(gòu)循環(huán)對控制器進(jìn)行試驅(qū)動 。 確保分配了實(shí)例變量，并且動作正確響應(yīng)。 控制器通常通過模擬方法來驅(qū)動。 照顧好控制器后，您將知道模型或域?qū)ο髴?yīng)該做什么。

Test-drive domain objects using the same red-green-refactor cycle with RSpec. Make sure that they provide the methods needed by the controller and the view. If you are working on a new feature for which a model does not exist yet, you should now generate the model and the corresponding database migrations. At this point you’ll know exactly what you need them to do.

使用與RSpec相同的紅綠重構(gòu)周期來測試驅(qū)動域?qū)ο?/strong> 。 確保它們提供了控制器和視圖所需的方法。 如果您正在使用尚不存在模型的新功能，則現(xiàn)在應(yīng)生成模型和相應(yīng)的數(shù)據(jù)庫遷移。 此時，您將確切知道您需要他們做什么。

Once you have implemented all the objects and methods you need and the corresponding specs are passing, run the Cucumber scenario you started with to make sure that the step is satisfied.

一旦實(shí)現(xiàn)了所需的所有對象和方法，并且通過了相應(yīng)的規(guī)范，請運(yùn)行開始的Cucumber場景，以確保滿足該步驟 。

Once the first scenario step passes, move onto the next one and follow the same steps. Once your entire scenario has been implemented — the scenario is passing, along with all underlying specs — take a moment to reflect if there is something that you can refactor further.

一旦第一個方案步驟通過，請移至下一個方案并遵循相同的步驟。 實(shí)施完整個方案后(該方案以及所有基本規(guī)范都已通過)，請花點(diǎn)時間思考是否可以進(jìn)一步重構(gòu) 。

Once you’re sure that you’ve completed the scenario, either move on to the next one, or show your work to others. If you work with a team, create a pull request or an equivalent request for a code review. Opening a pull request should automatically trigger a continuous integration build. When there are no more related scenarios left, show your work to your project manager or client, asking them to verify that you’ve built the right thing by deploying a feature branch to a staging server.

確定完成該方案后，要么繼續(xù)進(jìn)行下一個，要么向他人展示您的工作。 如果您與團(tuán)隊(duì)合作，請創(chuàng)建拉取請求或等效請求以進(jìn)行代碼審查。 打開拉取請求應(yīng)自動觸發(fā)持續(xù)集成構(gòu)建。 如果沒有其他相關(guān)場景，請向項(xiàng)目經(jīng)理或客戶展示您的工作，要求他們通過將功能分支部署到登臺服務(wù)器來驗(yàn)證您是否構(gòu)建了正確的東西。

This post is adapted from Rails Testing Handbook, a free ebook published by Semaphore. If you’ve made it this far and want to see some hands-on examples of writing behavior-driven code, download the book and let me know what you think of it. Thanks!

這篇文章改編自Semaphore出版的免費(fèi)電子書《 Rails Testing Handbook》 。 如果到目前為止，您想要看一些動手編寫行為驅(qū)動代碼的示例，請下載本書，并告訴我您的想法。 謝謝！

翻譯自: https://www.freecodecamp.org/news/how-to-build-rock-solid-ruby-on-rails-apps-with-bdd-735de9319cc6/

bdd cucumber

總結(jié)

以上是生活随笔為你收集整理的bdd cucumber_如何使用BDD构建坚如磐石的Ruby on Rails应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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