
Flutter — Discipline — New Feature
This is the first is a series of articles around disciplines.
They feel slow and sound harsh, but with good scaffolding and a bit of Kaizen (translate love) they are the key ingredient to focus and delivery speed.
My choice is to be feature driven, feature first, feature focused.
This article explains by example the disciplines used to add a new feature to the project.
Adaptive Theme Feature

Discovery
Business Requirement (Story)
Support automatic light and dark modes by changing the theme when the device brightness setting is changed.
Formulation


Automation
Start coding the steps and research and design as you go, when needed.
In this example we already have steps and code to detect devices and code to bring in themes and will need new steps for theme changes and phone settings.

To cover the new feature test statements I created three new *steps.dart files:

Each has a series of unimplemented steps to connect the given, when, then feature test statements with the code.

And a top level function to expose them.

I then wired them up in the gherkin_feature_test.dart file:

Run refresh features to complete the wiring using code generation:

Then run the new feature tests:

Wiring done, we can now write the new code to implement the tests and make them pass.
Starting with a brief design:

Ta Da


Code
Application Changes


During implementation I decide that the settings provider was not required, it fine to change a design once the you get into the details and I would expect the design to be thrown away once the code is implemented as we now rely on the feature tests and the code we used to make the tests pass.
Integration Step code examples



XP
With interruptions and writing the blog that’s a days effort.
You may say that’s too much! I could have just coded it in an hour.
That’s true but but it would likely be hard wired into a single widget build method and may have skipped the support of Whitelabel themes.
We now have code we can test and is documented by the tests.
That defends the feature from future regression caused by new features and documents the features in understandable way using English.
The bit of the discipline that annoys me the most is creating all the boilerplate code to wire up the feature statements into runnable steps.
I will be looking at scaffolding to help this soon, I know that the flutter_gherkin package has some pre-defined step definitions that use variables, so I will see what can be achieved, Kaizen!

Sound & Vision

