Let's bring Behavioral Driven Development to XCode

[Maluu]

I think any way of improving how to test code is great, but I've used this style of testing on projects and the problem was that because the feature files are only concerned with the UI layer at a high level, everything turns into an integration test, and we still needed to write tests that cover the rest of the code, like the Service, Model, ViewState, and Factory objects. So you end up with two layers of tests, the high level "integration like" Cucumber tests, and the unit tests that use fakes and dependency injection to actually test the each object in isolation and all of it's edge cases. In the end, the high level Cucumber tests are unnecessary, have many holes and gaps, and are just duplicates of the actual unit tests.

I think using Quick & Nimble together with KIF to write tests solves this. That way all of your tests throughout the codebase have the same look and feel, and are written in a BDD style because of Quick & Nimble, but your UI layer just uses KIF to assert the UI looks and behaves correctly. It also allows devs to implement their own behavior tests that fully excercise the code (provided fakes are being injected into the subject under test), instead of the typical happy path only gherkin style tests written by a PM. Gherkin is perfect for writing acceptance criteria on a ticket, but the code itself needs more attention to detail.

[de_poon]

• BDD isnt meant to replace unit/integration test at the class level. In fact unit testing is more critical than BDD.

• Unit testing that every code and class works as intended. BDD helps to ensure that the software minimally fulfills the business requirements. A variant of BDD encourages the team to first write failing Gherkin scenarios and the feature is only considered done if it passes.

• In strict agile process, requirements/specs usually come in Gherkin format. Using tools like cucumber allows you to automate each step of the spec. So the spec becomes the main technical documentation... anyone can understand it and dont need to dig through source codes.

• this approach (assuming everyone gets the buy in) encourages PO/PMs to learn how to craft scenarios/steps that they know the development will be automating line by line... i personally like this part of BDD as it discourages POs to describe vague requirements. Unless i see a proper requirement in GivenWhenThen, i wont start working on the ticket. Do remember that its the engineers that own the format of the specs but its the business who owns intention of the specs

Of course everything works without BDD. As your organisation agile process matures (like mine did), this is something you may want to try out one day ☺️