{"id":98,"date":"2019-07-08T14:46:17","date_gmt":"2019-07-08T14:46:17","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=98"},"modified":"2019-07-08T14:46:17","modified_gmt":"2019-07-08T14:46:17","slug":"story-based-bdd-an-alternative-approach-testing-with-ember","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/story-based-bdd-an-alternative-approach-testing-with-ember\/","title":{"rendered":"Story-Based BDD – An alternative approach testing with Ember"},"content":{"rendered":"\n

In this post we want to introduce you to a way, to test your Ember application: story-based BDD. BDD stand for\u00a0Behaviour Driven Development<\/a>. It combines the ideas of TDD (Test Driven Development<\/a>) with DDD (Domain Driven Design<\/a>).<\/p>\n\n\n\n

At its core is an ubiquitous, domain-specific language (DSL) using natural language constructs, that serves to improve understanding and collaboration between non-technical people with the domain knowledge (business analysts, product owners etc.) and developers. This language is used to describe the intended behavior of the software as a series of examples (“specification by example”).<\/p>\n\n\n\n

To give you a grasp on how that could look like, here is a real world example from one of our apps, a specification of how the cookie disclaimer we all learned to love should behave:<\/p>\n\n\n\n

  Scenario: Show a cookie disclaimer\n    When I go to the authentication page\n    Then I should see a cookie disclaimer\n    When I click the accept cookies button\n    Then I should not see a cookie disclaimer\n\n  Scenario: Hide accepted disclaimer\n    Given I have accepted the cookie disclaimer\n    When I go to the authentication page\n    Then I should not see a cookie disclaimer\n<\/code><\/pre>\n\n\n\n
At the same time, by being a semi-formal parseable language, often formalized using theGherkin syntax<\/a> as shown above, it serves as the foundation for implementing your (acceptance) tests: it provides the test specification<\/em>, that describes what<\/em> to test. Obviously that won’t be executable by itself, so the developer still has to provide the test implementation<\/em>, which defines how<\/em> to test it.<\/p>\n\n\n\n
OK, NICE, BUT NOW SHOW ME SOME CODE<\/h2>\n\n\n\n
If that maybe sounded a bit too broad to you, and you wonder how that actually translates into executable tests, I can understand you. So let’s dive into some code. Of course we don’t want to start from scratch, implementing our tests based on this paradigm. But luckily that are a number of solid test frameworks for story-based BDD for various languages: there is Cucumber for various languages, including Ruby, Java and JavaScript, Behave for Python or Behat for PHP, to just name a few. And guess what, there is also an Ember addon ember-cli-yadda<\/code>, that builds on top the JavaScript BDD library Yadda<\/a>, a JavaScript implementation similar to Cucumber. Its responsibility is to integrate the parsing of Gherkin-based feature files, its execution based on the accompanying step files, and the integration of all that into the command you are all too familiar with: ember test<\/code>.<\/p>\n\n\n\n
Important to note here is that it will not<\/em> replace all your testing stack with something completely new. To the contrary, it will run on top of either QUnit or Mocha (whatever you already use), and for the test implementation you continue to have all the testing tools from Ember and its ecosystem at your hands: async<\/code>\/await<\/code> with the beautiful test helpers from @meber\/test-helpers<\/code>, ember-test-selectors<\/code>, ember-cli-page-object<\/code>, ember-cli-mirage<\/code>, all covered…<\/p>\n\n\n\n
Also you can write some tests the BDD-way, and others using the traditional approach using QUnit or Mocha directly. In fact, as BDD’s natural language capability is quite suitable for describing user stories, I think it is quite common to write acceptance tests in that way, and continue to use the more lower level test frameworks for the lower level test types, like unit or component integration tests. At least that’s what we commonly do, so I will focus on acceptance tests for the remainder of this blog post. But technically there is nothing that would prevent you from using this addon for any type of test.<\/p>\n\n\n\n
But now, let’s finally get our hands dirty! As you can imagine, it all starts with this command:<\/p>\n\n\n\n
ember install ember-cli-yadda\n<\/code><\/pre>\n\n\n\n
This will automatically add a few files to our project, some I will come back to a bit later.<\/p>\n\n\n\n
MY FIRST FEATURE<\/h2>\n\n\n\n
For the purpose of this tutorial, we will implement some basic tests that will cover the error handling of our app. So let’s create our first BDD feature:<\/p>\n\n\n\n
ember g feature error\n<\/code><\/pre>\n\n\n\n
This will generate the feature file tests\/acceptance\/error.feature<\/code>, which holds our natural language test specification, along with its implementation in tests\/acceptance\/steps\/error-steps.js<\/code>.<\/p>\n\n\n\n
Let’s replace the dummy feature file with something more meaningful. For testing that our handling of page not found errors works correctly, we could specify that as follows:<\/p>\n\n\n\n
@setupApplicationTest\nFeature: Error page\n\n  Scenario: Error shown when visiting \/foo\n\n    Given I am an unauthenticated user\n    When I visit \/foo\n    Then I should see the error message \"Page not found.\"\n<\/code><\/pre>\n\n\n\n
So let’s quickly go through this line by line:<\/p>\n\n\n\n