Steps for hypothesis generator strategy

1. ✅ Write a script that can iterate through the DESCRIPTOR objects, and populate a dictionary (that looks like the kind of dictionaries that are exported when you do protobuf.to_dict).

   • This script should be pretty simple for the most part, but in the leaves of the tree, I’ll have to apply ideas from here 202005150918 Data generation for leaves of the trees.

2. ✅ Figure out how to get from (1.) -> Being able to write hypothesis strategy code that can interact with the created dictionary, and create sample dictionaries/JSON that have the same structure.

3. ✅ Figure out a test case where hypothesis will crash your code (this should be pretty straightforward though, especially if the hypothesis strategy generation is a little too forgiving, and allows some false positives to slip through).

   Related: Figure out what hypothesis.strategies parameters you need to have for you to easily prevent these false positives from happening. Probably in terms of some @assumes? Or restrictions on the characters that you can have while you’re building up your list of parameters. This is something that I’ll probably need my own abstraction for. This is lower priority though, doesn’t fit into the main workflow.

4. ✅ Create custom classes for things like Enums, and also make a custom class for configuration of hypothesis tests, based on the specifics of how I’m formatting the strings/floats/ints/timestamps.

5. ❌ Figure out how to print out / generate code in an algorithmic/iterative way, using the custom classes I’ve created.

   • Will probably need a mapping like format string to class name, and as I change/iterate through the list of names

     ❌ Something nice would be making sure it’s formatted properly, so look into running something like yapf on just a code snippet before printing it to the console

---

uid: 202005151135 tags: #theorem

---

---

---