Hey Thomas,
On Mon, Jun 14, 2021, 15:27 Thomas Nunninger <tho...@nunninger.info> wrote:
> Hi!
>
> > class UserPreferences {
> > private DB $db;
> >
> > function getColor(): string {
> > $preferredColor = $this->db->getColor();
> >
> > if ($preferredColor === 'light') {
> > return '#fff';
> > }
> >
> > if ($preferredColor === 'dark') {
> > return '#000';
> > }
> > return $preferredColor; // user has set custom color.
> > }
> > }
> >
> > Assume that both UserPreferences and getInfoPanel code is covered by
> > unit tests. The developer who made that change would run the tests,
> > see the tests pass and then push their code live. At which point, it
> > would cause an error in production, as the string returned would not
> > pass the is_literal check.
> >
> > This would be a complete pain in the butt to fix.
>
> When you write about testing in this database scenario, I find some
> additional issue: When you try to create pure unit tests you would
> somehow mock/stubb or replace the database with some test double. In
> that situation your tests will still pass even if testing the variant
> that the value comes from the database. Only some (infrastructure or
> end-to-end) test that covers the business logic plus the corresponding
> infrastructure by accident would uncover an error.
>
> I wonder if we would need some method to mark a value/variable as
> non-literal. Or perhaps mark some return value (or input parameters?) in
> an interface/class as non-literal using some annotation?
>
> That still puts the burden on the developer to think about that issue.
> But it's probably better than nothing.
>
> Perhaps someone has a better idea?
>
A small userland utility that writes the data to an in-memory stream, then
reads from it, is sufficient.
>
