Prune unnecessary files, rename confusing fules

[EvanKirshenbaum]

There are currently a number of files in the code base that are vestigial. This has a couple of consequences.

1. First, it makes it hard for somebody looking at the code base to know what's important and what isn't, and
2. Second, as the code base evolves, it breaks code that nobody may care about, but which MyPy will complain about.

My proposal:

1. Rename erk to utility (or something similar) so that it's more clear what it's there for.
   • Possibly go through types.py and figure out if there's non-DMF stuff that should be moved there. (MISSING comes to mind).
2. Make an unused directory (probably with subdirectories) for code that we no longer need but don't want to get rid of because it contains useful examples of things we might want to look at later.
   • This directory wouldn't be checked by MyPy, and so would be allowed to become out-of-date
3. Go through tools, tests, opentrons, and input and identify unneeded files, either deleting them or moving them to unused.
4. Refactor the tests directory to distinguish between
   • unit tests, which can and should be tested automatically,
   • examples, which we want to keep in the code base and want to maintain as working code, but which aren't things that we expect end users to use, and
   • scratch development scripts, which are developer-specific tests used during the development of (usually) a particular feature, but which aren't of interest to anybody else.
     • Arguably, these shouldn't be checked in at all, but it can be useful to be able to use GitHub to sync in-process development branches between, e.g., a desktop and a laptop, and each developer will probably come up with code they use on multiple branches.
     • I'm not sure what the appropriate rules are for breaking others' scratch code. Probably, these scripts shouldn't be checked other than, probably, your own on your own machine.

       Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 15, 2022 at 3:46 PM PDT.

[EvanKirshenbaum]

should we add another folder for integration tests? For example, I would have expected test_splashzones to be an integration (or maybe end-to-end) test

Migrated from internal repository. Originally created by Mark Huber on Jun 15, 2022 at 4:15 PM PDT.

[EvanKirshenbaum]

should we add another folder for integration tests? For example, I would have expected test_splashzones to be an integration (or maybe end-to-end) test

Possibly. We should probably discuss as a group what sorts of testing there are. (And we should almost certainly include Rares Vernica in this.)

I'm probably not the best person to be designing a testing plan because my own experience with automated testing has left me less than impressed. Code seems to fall into one (or sometimes more) of a few buckets:

1. Small and simple enough to be essentially obviously correct.
2. Contains errors that will be caught by the compiler (or, in Python, the type checker).
3. Dies on horrendously complicated and unforseeable corner cases (e.g., the first argument is an odd power of two greater than the second argument and the third argument is a negative number).
4. Works when compiled debuggable or when run in isolation, but fails when optimized or when other things are running concurrently.
5. Requires a huge amount of setup to run at all or requires resources (e.g., websites or mounted file systems) that may not be available.
6. Is inherently non-deterministic and, so, correctly returns different things each run.
7. Races with other code touching the same data and only dies when the race isn't handled correctly.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 15, 2022 at 4:57 PM PDT.