TDD – To Drive or Not to Drive?

TDD or test-driven development is a development process that encourages writing tests first before writing the actual code for the software. The idea is to write a test for a feature or a test that reproduces an existing bug in the software, make sure the test fails as expected, then write the code that makes the test pass, and finally refactor code if necessary and make sure the test still passes.

In my experience I have seen many developers and product managers argue about the benefits of TDD. First, stop arguing about it. Every developer and team is different, some do strictly TDD , some do it on occasion, and some not at all. We’ll leave that decision up to your team. I find TDD to be useful in scenarios that are not very straightforward and a solution is not easily attained. The test first approach could help jumpstart the problem-solving process in certain scenarios. TDD is often considered as a way to drive correctness of code from developers’ perspective.

What about RSpec and BDD?

An extension of TDD called behavior-driven development or BDD is a different way of looking at testing from a user’s or stakeholder’s perspective and created in a way that all parties involved in a project can understand. RSpec is a testing framework inspired by BDD that is widely adopted in the Ruby on Rails community. BDD and the decision to use RSpec should up to your team as well. If Rails testing that is supported out of the box is sufficient for the project, then there is not much need to use RSpec.

General Testing Guidelines

System Tests

System tests are important in environments that integrate Vue and Rails because it provides an end-to-end solution to testing the integration of the two technologies. The latest version of Rails supports system tests out of the box. System tests are essentially a wrapper around Capybara for writing clean and simple tests that interact directly with the browser using helper methods such as click_on, fill_in, and assert_selector. Before system tests were integrated into the Rails framework, configuration was necessary for this to work, and JavaScript was not supported out of the box.

So, the preceding code covers a happy path of a game from start to end with one winner and one loser. We’ve defined a couple helper methods – play and assert_piece. The play method clicks on the appropriate board position and assert_piece checks that the appropriate piece has been played. For this to work, we also need to define an id attribute on the related SVG element such as “X5” denoting that an X is visible in the fifth board index. Helper methods can be defined in the ApplicationSystemTestCase class since all our test cases for system tests extend from that class.

What about other scenarios such as a tied game? Or a different board configuration? We could create a few helper methods to cover these scenarios in a system test, but it is not the best approach. Each system test adds a bit of overhead to the time it takes to run your test suite. These scenarios would be better covered in a typical Rails unit test. If there is a UI scenario that needs to be covered, we could also use Jest and Vue test utilities to create a unit for a particular Vue component. This leads us into the discussion of such testing tools and frameworks that we can use for unit testing Vue components.

Vue Test Utilities and Jest

When unit testing Vue components, it is easy to get carried away with testing lots of edge cases just like it can be with system tests. So, it is important to think about the important pieces of a component. Take the Board component in the Tic Tac Toe game, for example. It would be unrealistic to test every possible board configuration, and we aren’t necessarily even interested in that since a game object is passed down as a prop. The important part of the component is testing that when a player clicks on a certain board position, it results in the appropriate action being called; in this case, it is the Vuex action for games_players/UPDATE. The vue-test-utils documentation has some good examples on testing Vuex action, so we will follow those guidelines for testing this scenario.

Heroku vs. Virtual Private Server

There are plenty of cloud providers that offer virtual private servers (VPS) such as Digital Ocean, Amazon Web Services, Google Cloud, and many other providers. A VPS is a server that runs in a virtual environment on shared physical hardware. Hardware is maintained by the cloud provider, so swapping out bad disks, CPUs, etc. VPS providers often give you the choice of which operating system you would like to run with different flavors of Linux such as CentOS or Ubuntu. This may be a viable option for developers who also like to get into the nitty gritty of system administration or have more resources to support maintenance and monitoring of the servers. Be sure to weigh in on all the tradeoffs of this approach. We have listed the advantages and disadvantages of each option for you to evaluate.

Continuous Integration and Deployment

Whether we are using Heroku or a VPS, we can take advantage of various continuous integration services such as Travis CI to combine and automate our test, build, and deploy process. This will come in handy especially if we want our application to support different browsers. If you are developing in Chrome on a Mac, how do you know if our Vue components are supported on Firefox on a PC? A great service for this is BrowserStack and provides the ability to test various browsers on multiple operating systems. We can ensure our testing phase passes before the application is deployed to production. Also, if we need a finer grained release management, then we can choose only to deploy when a release is tagged in our git repo or under other conditions. We will demonstrate how to set up Travis CI to include a custom test and deploy process which integrates with BrowserStack and Heroku. To get started you’ll want to sign up for accounts at travis-ci.org and browserstack.com.

BrowserStack

BrowserStack has the capability to run its tests against our local test server, but ideally, we want to run the tests against our staging environment on Heroku to test an environment as close as possible to production. System tests use Capybara under the hood, so we can simply set our app host for Capybara in our test/test_helper.rb file.

Capybara.app_host = 'https://staging-app.herokuapp.com:443'

You’ll notice that our Travis CI configuration for the BrowserStack stage includes a TASK_ID variable in the command. Our code for setting up BrowserStack uses this value to determine which browser to run against. We can define a config/browserstack.yml file which includes this configuration.

server: "hub-cloud.browserstack.com"

common_caps:

  "browserstack.debug": true

browser_caps:

  -

    browser: firefox

  -

    browser: chrome

  -

    browser: safari

  -

    browser: internet explorer

We can now setup a custom Capybara driver that uses the TASK_ID to select the appropriate browser to run against.

TASK_ID = (ENV['TASK_ID'] || 0).to_i

CONFIG = YAML.load(File.read(Rails.root.join("config", "browserstack.yml")))

CONFIG['user'] = ENV['BROWSERSTACK_USERNAME'] || CONFIG['user']

CONFIG['key'] = ENV['BROWSERSTACK_ACCESS_KEY'] || CONFIG['key']

Capybara.register_driver :browserstack do |app|

  Capybara.app_host = 'https://vueonrails-ci-staging.herokuapp.com:443'

  @caps = CONFIG['common_caps'].merge(CONFIG['browser_caps'][TASK_ID])

  Capybara::Selenium::Driver.new(app,

    :browser => :remote,

    :url => "http://#{CONFIG['user']}:#{CONFIG['key']}@#{CONFIG['server']}/wd/hub",

    :desired_capabilities => @caps

  )

end

You’ll notice that the code uses BROWSERSTACK_USERNAME and BROWSERSTACK_ACCESS_KEY environment variables. We can encrypt these values to include in our travis config file using the travis cli, for example.

travis encrypt BROWSERSTACK_USERNAME=...

Finally, we just need to update our test/application_system_test_case.rb to inform Rails to use the Browserstack server by using the driven_by method.

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase

  driven_by :browserstack

end

And that about wraps things up for using Travis CI to automate a lot of tasks that we often see in development environment that moves a quick pace and quick iterations. Let’s see how our tests performed in the Travis CI dashboard (see Figure 7-1)

DOH! ... always causing problems IE. Good thing we didn’t deploy it to production. Note that our Travis CI configuration doesn’t include a deployment process to production, but this can be easily done by adding another deployment stage once all previous stages have completed in a similar manner to our staging deployment. Following a good process for getting your app into production isn’t always clear especially for small development teams that also need to do their own DevOps, so we wanted to make the testing and deployment phase of a project straightforward and hope you appreciate our approach which aligns with our philosophy of simplicity.