#BDD

When I read The BDD Books: Formulation Then I become a better Software Crafter

My review of the new #BDD book by @gasparnagy
and @sebrose:
https://coderbyheart.com/bdd-book-formulation-review

#bddbooks

Pretty happy today with my #BDD setup, where I can document the contract for a
third party API in the same feature file that describes the effect of using it.

The calls to the 3rd party are mocked, everything else run on a real instance.

This is a great example of why I like #BDD #e2e tests and how they support
refactoring: the only thing that changed (while refactoring the entire data
storage solution) was the query language part, the result, and tested scenarios
stayed the same.

Bringing external data into scenarios to make the data reusable:
https://gojko.net/2020/11/02/given-when-then-tweak-try-again.html #bdd

This is the test platform that we use to run the
@bifravst firmware on real hardware for every
commit.

See
https://bifravst.gitbook.io/bifravst/cat-tracker-firmware/firmwarecontinuousintegration

The tests are expressed using a #BDD style, written in #Gherkin:
https://github.com/bifravst/firmware/pull/82/files#diff-8140b13bf416d834ea873f009052f8121e7080e3fb6a4b6d9f00b20adbdd6114

I've now written the first #gherkin #bdd features for testing the
@bifravst firmware on real hardware:
https://github.com/bifravst/firmware/blob/d3903b83c5aa3f75acedcc79d7171c9786241c9f/features/RunFirmware.feature

I think that's a good way to express what should happen when the firmware is
running.

Here is another example of a feature:
https://github.com/bifravst/firmware/blob/d3903b83c5aa3f75acedcc79d7171c9786241c9f/features/CheckModemFirmware.feature

Given a log output (from a test run on real hardware), I want to express
assertions against these logs. Are there any existing test frameworks that use
that approach? It's like #BDD testing, but without any interaction (the firmware
can be configured to behave in a certain way).
/status/1314316412249350151

#BDD was born to simplify adoption of #TDD but it didn't take off.

Today I started to work on #BDD #e2e tests for a cloud-native app, means I need
to test directly against the @awscloud SDK.

@cucumberbdd feature file:
https://github.com/bifravst/aws/blob/a42789d8fd79578a315feb54f7e1f3cc93eea412/features/IoTUserPolicy.feature

and this is the testrunner implementation:
https://github.com/coderbyheart/bdd-feature-runner-aws/blob/fef4f244bc0c278703a6c51f4e179e2d7c888543/src/steps/aws-sdk.ts

A day's work and we have nice #BDD e2e tests for our #GraphQL API running on
@awscloud #appsync.

Getting invited to speak @EuroTestingConf
about how I #BDD components which you can't run on your machine (because #cloud)
makes me be like:

Currently writing a custom Gherkin runner which runs our integration tests and
nicely shows interpolated steps, can skip if stuff fails, etc. #bdd

Writing #BDD tests in Gherkin sounds strange to you? Give it a try!

Yes, the underlying implementation that needs to be build will blow your mind.
You need to handle state between and map a linear model of test execution to
something which used to be hierarchical.

This is a nice #bdd exercise: #EuroTestConf

Try not to express implicit behaviour in your #bdd scenarios, they mostly add
noise. #EuroTestConf

My slides about the browser-based testing with #BDD / Gherkin are here:
https://docs.google.com/presentation/d/1n_iauHDuqIListuMcsvr3SkYbCISwrdPWbvgv7Gy2yw/edit
#unKonf

An open source repo where I test the API with Gherkin stories:
https://github.com/ausgaben/ausgaben-node #bdd #tdd #unkonf

Cool! I'll be talking about testing frontend code #bdd style with #nodejs at
#etffm16 https://entwicklertag.de/frankfurt/2016/