Expand character set for text input generation

[malted]

Trying to understand where your head is at with the bigger purpose of this lib. Feel free to close as not planned.

I'm thinking about some classes of textual input bugs that are not caught with the current const ALPHANUMERIC characterset. Null characters, spaces at ends of inputs, weird unicode, etc etc etc.

From what I understand that's not the goal of Bombadil - you seem to be more focussed on fuzzing the interaction graph rather than the wider input (nav, text, otherwise) space.

I'd like to explore this if you think it's within scope.

[owickstrom]

Hey! It's not a non-goal, just haven't focused on it. For some targets it might be less interesting, something you wouldn't want to spend energy on exploring. But in other cases it really might be. So I think this should be configurable, like maybe the inputs action generators is based on a function inputsFrom (or some better name) that takes a character set? Not sure, but that seems plausible. Then you could use the function to create a generator with another set.

Another consideration is that we (at Antithesis) have considered using Hegel as a backend for generators in Bombadil, which would get us a lot of interesting string generation for free, but due to some incompatibilities that hasn't happened yet. For now, I think it makes sense to build out more stuff in Bombadil even if we decide to switch approach later.

Would you wanna do a PR for it?

[malted]

Yes!

I assume you mean inputsFrom should return an ActionGenerator. I'm struggling to decide where to put these sorts of configurations. Down the line there will be more.

I thought about wrapping inputs itself (which would allow for, say, a completely custom action generator to be passed down the line) but it would probably create all sorts of conflicts with the default export method that's currently being used.

Some sort of global mutable state then? Would it be appropriate to keep an object on the Runtime singleton for configuration?

FWIW, I think a nice API would look like a configure function that just writes to runtime.config. Having to define a whole new ActionGenerator for something this simple feels overly complicated.

Thoughts?

This is stupid. I'm putting a new action generator in lib/bombadil/src/specification/extended/actions.ts.

[owickstrom]

Looking at this again, I wonder if the right call isn't to make the building blocks more configurable rather than trying to make defaults members more configurable.

I.e. make the strings() function accept a child generator that generates single characters. Something you'd construct using chars() or chars(<some char set array>). And if not supplied to strings(), it uses a char generator based off ALPHANUMERIC, basically what we already do today.

Then you'd construct the text entry action based on the strings generator.

[owickstrom]

There might be a case for the default text entry to generate more interesting inputs in any case, like unicode sequences, emojis, whatever. In that case we should decide to just make that the default, rather than making defaults configurable. (Sorry, I didn't think this consideration through before.) In any case, making the building blocks in random more composable is good.