BDD: It's not your test framework, it's you

Notes

brittle tests do not reveal intent. they explain how, not what.
create your own DSL about the important things your domain
reuse these in your tests
develop test framework independence
program by "wishful thinking" to create your DSL
BDD was created to support a process of product owner collaboration
stop annoying product owners
let them use their language and transform it into our tests. not the other way around
if BDD tests are hard to write, you are not going to read them
documentation is the reamining 5% of a good BDD process
you may not need the docs
tests + gherkin may be enough
developers hate running slow tests
continuous integration is a confidence booster
"sleep" in a test means a developer has given up!
prayer driven coding
assign a rotating build nanny to triage flickering tests
delete burdensome tests!
do not test "login" 50 times
Functional tests
Journey tests are those that are black-box test that run a critical path
Functional tests are white-box tests. Can stub out authentication.
Implement tests from the outside in
You may not need to commit all the tests to the code base
Or tag the tests and only run them on CI (don't overdo this!)
BDD does not always have to go through the browser. tag as "no-ui"
treat test code as first class citizens of the code-base
focus on the common paths, not just happy paths