Behavior Driven Development Frameworks for Swift

DZone 's Guide to

Behavior Driven Development Frameworks for Swift

This article lists some of the major tools available for iOS Xcode projects to support Behavior Driven Development and their features and requirements.

· Mobile Zone ·
Free Resource

Recently, there are various companies looking for BDD supporting tools for iOS apps written in Swift. As there is no official support from Cucumber for Swift, most of them are struggling to find the right BDD tool for Swift projects. This post will highlight some of the tools that support BDD in the Swift applications. BDD, a.k.a. Behavior Driven Development, is the process of developing an application by using executable specifications in Gherkin or something similar so that programmers can use those specifications for development and business people can use them as requirement specification or living documentation. BDD is an outside-in development methodology. You can read more about BDD here.

Behavior Driven Development in the iOS world was always challenging because of the lack of proper BDD tools, like Cucumber in Swift. In website development, there are language-specific options for BDD. There are some tools which parse the Gherkin language syntax (Given/When/Then) and we can execute BDD scenarios, e.g. Cucumber for Ruby, CucumberJS for JavaScript, Cucumber-JVM for Java, SpecFlow for C#, and Behat for PHP. There are also some tools for Spec-level BDD, like RSpec for Ruby, PHPSpec for PHP, and Jasmine for JavaScript. However, in the iOS world, there are very limited options to perform BDD, especially for Swift. In this post, we will explore the current BDD options for Swift iOS apps.

Gherkin-Style BDD in Swift

Gherkin Style BDD might be easily achieved with tools like Cucumber with Appium or Calabash, but supporting BDD inside Xcode isn't straightforward. BDD in the iOS world was always challenging because of the lack of proper BDD tools like Cucumber in Swift. There isn't any Gherkin parser available in Swift, so the Cucumber community suggested using an Objective-C Gherkin parser. There are multiple BDD tools to write lower-level tests, mentioned here, but in order to write UI-level tests, there are very few options, which may not have all the core features of Cucumber in Ruby.


XCTest-Gherkin is another tool that can be used to achieve BDD in Xcode projects. There is good information about its features and limitations in the README file. It has pure Swift representation, and we can still have GWT (Given When Then) written in the String format, but the major drawback is that we cannot write or execute .feature files and it lacks many core Cucumber features like tags and filtering features. You need to get XCTest-Gherkin as a dependency for your UI Testing target using CocoaPods or Carthage.


XCFit is another pure Swift implementation to support BDD in Xcode projects. It also gives Xcode templates to get started with BDD, the Page Object Pattern, and the Protocol Oriented pattern. XCFit has some pre-defined steps in Swift frameworks, but the quick benefit comes from Xcode templates. More information on Protocol Oriented BDD can be found here. Again, the major drawback is that we cannot write or execute .feature files and it lacks many core Cucumber features like tags and filtering features.


Cucumberish is a test framework that can be used to write features in the Gherkin format and can be executed from Xcode. Cucumberish is written Objective-C and uses the Objective-C Gherkin parser from the Cucumber repository. It's great to be able to execute Gherkin feature files from Xcode, but Cucumberish has some bugs and needs workarounds for most cases. Also, it's a bit tricky to introduce Objective-C dependencies in a fully Swift project. Cucumberish can be imported to UI Test targets using CocoaPods or Carthage.


Ploughman is another test runner for the Gherkin language where we can write and execute feature files from the command line. There is good information in the README file of  Ploughman. This lacks a lot of features of core Cucumber, like examples, tags, and filters. This package can be imported using Swift Package Manager.


SwiftGherkin is another Swift package for working with Gherkin-based .feature files. This is a newly created package with support for Features, Scenarios, Scenario Outlines, and Steps, however, there will be support for all other core Cucumber features in the future. You can stay tuned with this repository for more news on this package. This package can be used with Swift Package Manager only.

Spec-Style BDD in Swift

Similar to RSpec for Ruby, PHPSpec for PHP, and Jasmine for JavaScript, there are a few tools where we can write the specification for lower-level implementation. We will see those spec-level BDD options in Swift.


Sleipnir is a spec-level BDD-style framework for Swift which is highly inspired by Cedar from Objective-C. This is probably the first-ever BDD-style framework announced for Swift. You can read more about the inspiration and introduction of BDD to Swift in this blog. However, Sleipnir does not use the XCTest framework and it is not supported for iOS at the moment. It isn't also properly supported by CocoaPods.


Quick is a very mature RSpec-style framework for Swift. Quick comes with the Nimble matcher, which makes the DSL much readable. Quick is compatible with CocoaPods, Carthage, and Swift Package Manager. It's been used for as a replacement for Apple's own XCTest framework as specs become much more readable using the combination of Quick and Nimble. There are many popular projects which use Quick; some of them are listed on this page.


Behavior Driven Development is a collaborative process which isn't dependent on tools, but having BDD-supporting tools makes collaboration much easier. The goal of this post was to list major tools available to support BDD for Swift projects. Please let me know if I missed any tools.

mobile ,mobile app development ,swift ,ios ,bdd ,xcode

Published at DZone with permission of Shashikant Jagtap , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}