Quick thoughts on tests

• recently was reaching for Dark tests when writing PrettyPrinter fns

• where do tests live? how are they maintained?

• unit tests separate from functional tests

• unit tests are owned by the tests they’re around

  • can be GC’d
  • fns that are only called by unit tests are deprecated. And the ones that are called by functional tests are no deprecated?

• functional tests aren’t owned and just live at the root? or within a module?

• functional tests will likely be more impure than other things

  • httpclient calls
  • might start integrating tests and mocks
  • result of httpclient call is basically a mock
  • traces → tests (button?)
  • also, traces from one-off fn calls
    • TODO: stachu draw out idea about creating tests from one-off calls in an actual REPL

• (how) do tests interact w/ http handlers? crons? etc.

• “chat interface is a REPL” (these sort of interactions fit just as well in a CLI)

  • $ → code
  • > → talk to AI
  • edit function → Vim (with Dark plugin)
  • in browser, we have 3 window thing
    • tasks
    • chat
    • code snippets under discussion
  • in CLI/REPL,
    • can run code
    • can get to equivalent of ‘right column’ via commands like edit fn

• a thought

  • rebrand REPL as Script
  • a Script is a thing that you run
    • “what is a snippet and where do snippets go?”
  • what if we threw away current “REPLs” and just used fns instead
  • http handler is just fn w/ specific inputs/output (http request, http response)
  • repl is just fn with string args
  • cron is just a unit fn called at specific time
  • worker is just a fn called with an event specific time
  • AI can allow us to call any fn from any context
    • or adapt fn from any context
    • e.g. call System.random, which expects an int. called in CLI, ai could take string argument and convert it into appropriate call
    • “give me random number from 1 to 100” →
  • snippet is a collection of types and fns
  • they can be versioned
  • ? most systems have handlers
  • handlers exist because we want to have a piece of code on a canvas to look at
  • handlers could have expr just to map from the inputs to the fn args, and from the fn results to the handler results
  • “snippets don’t fit nicely into any of the shapes we have right now in ProgramTypes”
  • most natural destination is “REPL” which is weird
  • (DBs don’t follow this logic totally — though, DBs are ‘just a type’)
  • “snippets are a collection of types and functions”
    • Q: like - an ordered list of tlids that references them externally, or are they fully owned by the snippet?
  • “what we are producing in an AI session is a PR”
  • this is where feature flags come in
    • use feature flag to use something in a branch/snippet/etc.
    • branching is a construct for releasing fns (and types) to end users
    • if we want to replace part of tyhe prod codebase w/ new stuff, FF concept where branch is chosen based on [condition], to [portion of people based on condition, e.g. “5% of users”]
  • snippet is a branch; new snippet iteration is a fork of that branch; can revert etc
  • produce tree of exploration that you did; every gets a new version
  • TODO: reread git source for inspo
  • snippet → git checkout -b paul/project-x or w/ timestamp or something
    • branch becomes part of type name and version numbers
    • don’t just get User_v1, _v2
    • more like we have paul/project::User
    • misc: can reference fns/types from one branch in another branch
    • feels like Unison TODO: review Unison
  • snippets exist as/with metadata
  • misc: as a general take-away, seems worth iterating on how we think about versions - vX seems insufficient

• for now

  • fns and types are what matters
  • snippets → fns and types
• • let’s suppose AI returns MyType and myFn
  • save those to the canvas as MyType_v0 and myFn_v0
  • later the AI produces produces new functions/types
  • save those to the canvas as MyType_v1 and myFn_v1
  • deprecate MyType_v0 and myFn_v0

• (explicitly, later, we will come up with a more complex branching/naming scheme)

• constants/”values” fit nicely into this as well

  • (same kind of versioning situation)

• still need to chat more about Tests and REPLs/scripts and how they fit into this

• the real REPL experience is embedded in the “conversation view” UI, and AI I/O is a piece of that

• “CLI = REPL”

• darklang → repl