《纽约时报》让不懂编码的同事皆可参与开发过程，将一个产品功能拆解成一句句简单易明的文字，展现一个功能在不同情景的变化，但不会阐明具体详情，只追求清晰简单易明。此方法的步骤简单，产品经理先写一个用户故事，再联同发展人员转换成一份功能文件 (Feature File)，例如将故事拆分为 场景 、 假设 、 当 和 那麽 ，并以简单句子逐一描述。成品完成后，可作为有份撰写的开发人员的自动化点对点测试大纲。当点对点测试通过后，再将整个测试框架嵌入持续整合管道 (Continuous Integration Pipeline) 。降低门槛，人人清晰明白用户故事，提升团队协作效率，何乐而不为？
No Code? No Problem — Writing Tests in Plain English
open.nytimes.com
Illustrations by Dalbert Vilarino
How we use Behavior Driven Development to better collaborate
By NAIDELE MANJUNATH and OLIVIER DE MEULDER
Behavior Driven Development, or BDD, is an approach to software development where the behavior of a feature is defined through examples in plain text. These examples, known as feature files, are defined before development starts and are used as acceptance criteria for new features. Written using the Gherkin language, which uses English words, the feature files are readable to anyone regardless of programming ability. Feature files are written in a “behavior-driven” style, meaning they contain details on how a feature is supposed to behave when something happens in a given situation. This behavior is the only information that is mentioned in the feature file; the underlying implementation details of the feature are not mentioned.
Our cross-functional team — the Customer Care Technology team at The New York Times — uses feature files to have deeper conversations about our product, which helps create a shared understanding of what should be developed. When everyone understands our user stories, we waste less time in the production process and have fewer instances where we redo the work we’ve done. Writing feature files together encourages collaboration, and helps developers and QA understand the business aspects of the story.
Because anyone on the team can read and write feature files, we don’t need to rely on testers or QA engineers to write the tests.
Our process
At the beginning of each sprint, our product manager writes the user stories for each feature, following Agile principles. Here is a simple example of a user story that we might include in one of our sprints:
As a customer care advocate, I want to update a customer’s credit card on file, so that the customer’s new credit card will be charged during the next billing cycle.
When the user stories have been written, our product manager and our developers sit together to translate the user stories into feature files. The feature files serve as the outline for the automated end-to-end tests that the developers are responsible for writing.
Following our example of a user story above, the feature file may look like this:
The automated tests are written in Javascript. Each Given, Whenand Then line in the feature file correspond to a simple Javascript function, and the Then line will contain the test assertion. Our team uses the Mocha assertion library, webdriver.IO as a test runner and the Cucumber framework to interpret the test feature, but any can be used. The developer working on the automated end-to-end test can run the test locally on their machine.
And this is where the magic happens.
The test runner parses the feature file, figures out which JavaScript functions to run and reports back.
Once all the end-to-end tests pass successfully, there is one more step. The BDD testing framework is integrated in our continuous integration (CI) pipeline. This allows everyone to verify that the tests run in the staging environment.
A report from the test may look like this:
As you can see, the report is easy to read, even if you do not have a technical background.
Illustration by Dalbert Vilarino
So, what makes BDD worthwhile? Our team has seen four tangible benefits:
Increased collaboration. The product manager is involved in designing the tests, which means they work with the developers (and QA, if applicable) to clearly state the business rules. Everyone on the team has a strong understanding of new product features and the progression of the project is clearly visible to each member.
Living documentation. Because the feature files serve as the checks before features reach production, they need to be kept up-to-date. Any modifications to the product or features means that the files have to be updated to avoid failures caused by the feature definitions. While documentation is often an afterthought in software development, BDD makes it an integral part of the development process.
Quick Ramp-up. Code doesn’t make sense to everyone. It also doesn’t make good documentation. Working with team members who don’t understand code usually means that the team has to create a separate document, like a spreadsheet, to describe what is covered by the test code. BDD helps solve this problem with feature files. Newcomers to the team can read feature files and quickly understand what the feature does. This is better than going through tons of documentation.
Readable Reports. Usually, test results are not presented in a user-friendly format — a log in the report could say something cryptic like, “expected false to equal true.” Although this may be simple to read, the context or meaning is not clear to the reader: what was expected to be true and is now false? With BDD results, each result falls under the corresponding scenario in the BDD feature file, which provides better readability.
Our team started using BDD a few months ago. At first it was a bit scary and overwhelming because everyone needed to learn a new technical skill and work together in a new way. Over time, the team mastered BDD testing and found that working closely together was a very natural process. When the team collaborates on feature files, we’re more aligned on the development cycle and the product becomes better.
Naidele Manjunath is a Software Engineer with The New York Times Test Automation Team.
Olivier De Meulder is an Engineering Manager with The New York Times Subscription Platforms Group.
