Nate wants to experiment with the UI, but Twitter keeps getting the results.
- "This thing that we're making because we're lazy has now taken 4 or 5 weeks to implement."
- Last week: "worker" logic vs "decider" logic. Allowed us to flatten the logic.
- "You can spend months on the backend and people think you've barely got anything done. You can spend two days on the UI and then people think you're making progress."
- (04:20) Now we want to work on the UI, but we don't want data to post to real Twitter.
- "Why do you keep posting 'asdf asdf asdf' to Twitter?"
- UI development involves a lot of exploration. Need to try things out with data.
- We want to be able to control the data we're working with.
- "We want carefully-curated abnormal data to test the edges of our UI."
- (06:30) We could have a second Twitter account to fill with junk data.
- Or, we could use the Twitter API sandbox.
- Problem: we don't have much control over the data set. Eg. We can't just "reset" back to what it used to be.
- Problem: what about when we're hacking on a plane?
- Plus, we want to be able to share test data between developers.
- (09:10) What can we do instead? Let's make a "fake" Twitter service we run on our machine.
- "Fake" Twitter gives us something our application can talk to that is under our control.
- Having a "fake" Twitter service creates new problems
- Project wants to grow larger and larger
- Now we have to run more things
- Creates more obstacles between checking out the code and getting work done
- (12:35) Rather than a "fake" Twitter service, we want to "fake it" inside the application.
- What is "faking it"? Is this the same as "mocking"?
- Use a protocol for our Twitter API "handle". Allows for an alternative implementation.
- Not the same as mocking
- We are not trying to recreate all the possibilities.
- We are not trying to use it to test the component code.
- The purpose is different than mocking. The Twitter "faker" is to help us work on the rest of the application.
- The "faker" is about being productive, not about testing.
- (17:20) Can have the faker start with useful data.
- Default data in the faker can launch you straight into dev productivity.
- "You want automation to support your human-centric exploration of things."
- "If your environment is as fast as it can possibly be, then it allows you to be as fast as you can possibly be."
- (20:10) Can use the faker for changing the interaction
- Eg. have a "slow" mode that makes all the requests take longer.
- Useful to answer the question: "What does this UI feel like when everything gets slow?"
- "The faker can implement behavior you need, for exploring the space you need to cover, to converge on the right solution."
- (22:00) Can have the faker pretend something was posted manually.
- Allows you to see how the UI behaves when the backend discovers a manual post.
- (23:00) Goals of faking
- Support exploration. Not about testing and validation
- Support the human, creative side of development
- Support the developer experience
Related episodes:
Clojure in this episode:
defprotocol
defrecord
component/system-map
Related projects: