jedifans

The ability to scan the whole of a request body rather than just the first 8kB.

Using a HorizontalPodAutoscaler [1] you can scale up and down the amount of "pods" (a grouping of containers that are scheduled as a unit) based on the desired metric.

[1]: https://kubernetes.io/docs/tasks/run-application/horizontal-...

https://cloud.google.com/kubernetes-engine/docs/how-to/preem... states that preemtible VMs aren't guaranteed to be available.

Try not to see a feature file as a way to automate tests but to capture the requirements in a language that isn't technical.

Business rules change far less often than implementations, so the feature files shouldn't be tied to the implementation - that tying together can happen in the ruby code that implement the steps. You can refactor that code easily but the feature is denoting the business rule.

Before the feature files get written, have a conversation with the PO and other stakeholders.

Involve a QA person and relevant developers.

Catch the changes early, ask for more examples of the feature or goal, "have you thought about ...", "What happens in this case...?".

You will get better quality features with less rework, because you are writing the thing the PO actually wants and cover off edge cases before they crop up in testing.

Cucumber and other tools such as Behat allow you to capture conversations you have with your client, product owner and stakeholders.

They enable you to build the right thing - the thing that helps the users or meets the business goals.

Have a look for BDD, Behaviour Driven Development.

The main thing is to have the conversations. The automated tests are a lovely side effect!

At the very least, I think Tom Watson MP will call this out.