swift-testing
swift-testing copied to clipboard
swiftlang
Support given–when–then (aka BDD) testing style
Description
A useful technique for arranging tests is to use a given–when–then style (as commonly used in behaviour-driven development). This is supported in a large number of testing frameworks (e.g., Quick for Swift, GoConvey for Go, JUnit 5 for Java using nested tests). Unfortunately it is not supported in Swift Testing.
Supporting this style would allow tests to be structured hierarchically according to the setup code shared by groups of tests, enhancing readability and reducing boilerplate setup code. This is consistent with the Swift Testing vision to be expressive, flexible and scalable.
Expected behavior
No response
Actual behavior
No response
Steps to reproduce
No response
swift-testing version/commit hash
No response
Swift & OS version (output of swift --version && uname -a)
No response
@rodcheater thanks for this issue! I'm personally very invested in BDD as a technique, and so far have been pleased with how I can use Swift Testing to achieve some of the workflows I know from other BDD-labeled frameworks.
We're well aware of the Given-When-Then (GWT) paradigm (and some of us involved in the project have used it, myself included). In prior discussions about how to shape and design the framework, we arrived at the decision that Swift Testing should be a framework of primitives that enable many different kinds of tests and testing frameworks to be developed, including Cucumber or Gherkin-styled frameworks.
Towards that end, we've generally believed it's best to keep DSL-based or opinionated test designs, such as GWT, out of the core framework since they may not be suitable in every application, or there are developers who may prefer alternate approaches to test design. GWT, Arrange-Act-Assert, and other ways of organizing pre-conditions, invariants, and post-conditions come down to personal opinions and experiences on the best way to organize test logic, and we seek to enable all of these designs without having to implement them in the core framework. In a lot of ways, Swift Testing is to Quick as Foundation is to UIKit.
If you encounter, or believe, anything in the current design of Swift Testing prevents the creation of the Given-When-Then framework you're envisioning, we would be eager to see what you found so we can see whether we can improve the framework for your needs.
I'm very interested in there being a BDD-style DSL for Swift Testing. Whether that's providing that directly in Quick or some other mechanism. I haven't yet started a spike implementation, but you can imagine that just like how I'm committed to providing BDD tooling for XCTest with Quick, I also want to make sure that BDD tooling exists for Swift Testing.
I guess what I was hoping for was a Swift Testing–native way of doing BDD-style testing, rather than relying on a third-party framework to provide this functionality. The expectation would then be that tooling such as Xcode would be able to reliably pick up tests and show the usual UI affordances for selecting tests to run.
To distill Seán's comment a bit: it's not something we're planning to build ourselves, but we do want to make sure Swift Testing is able to serve as infrastructure for other projects like Quick that developers can use.
I know that's probably not a very satisfactory answer! We'd be happy to discuss further over in the Swift Forums.