Refactor to add widget tests

Notes on refactor to add widget tests.

There are many reasons to do this, and keeping notes on those reasons may contribute to maintaining motivation and priority.

• code coverage, and CI test for minimum coverage
• automated screenshots for store listings
• lower chance of bugs in a release
• may encourage better understanding of framework
• encourage refactor to separate logic from layout and display
  • among other side effects, this may encourage:
    • designing layouts for different screen sizes... currently only small screens are taken into consideration
    • a11y, i18n, l10n
• adding new features may be easier

I'm in the process, and it's a somewhat large task, and at times the subtasks are not clear. I may also keep notes here on what areas of the code could use some refactoring.

• StorageWidget is somewhat of a mess
• Profile and Query UIs appear to be not very "functional", in the FP sense
  • In other words, UI/layout code seems to make direct calls to memory, which doesn't seem ideal for writing widget test

Related tasks:

• Add test coverage to taskc library
• Bump Taskwarrior from 2.5.3 to 2.6.2, in Docker image for CI
• Add test coverage for the flutter task app

What motivates each change? Are you simply increasing code coverage?

The primary driver for refactoring is to write widget tests. The primary driver for the widget tests is code coverage. This doesn't really guarantee any behavior in the app. If I understand correctly, code coverage just checks that a line of code was called during tests. It does not indicate that some particular behavior was checked. I hope to emphasize that later. I don't think emphasizing code coverage is a waste of time. I think in the process of increasing the code coverage, I will be structuring the code in a way that makes it easier to write tests for, and once I return to the code to check that various behaviors are guaranteed, that process should be easier than if I hadn't first gone through the project increasing code coverage.

I do think increasing code coverage will encourage cleaner code, for example separating logic from layout and display, as well as code that is easier to modify. And that all should make it easier to later write tests that check for widget behavior.

But, code coverage alone can indicate that at least those widgets don't error simply by being called. There is that immediate effect.

Where?

There are four subdirectory packages, i.e., task, taskc, taskj and taskw. Only task depends on the Flutter SDK, and the other three already have a significant amount of tests.

Recently, task only had the default widget tests, and it failed. Work is under way to add a significant number of widget tests, and refactor the code to keep these widget tests manageable.