Testing and Refactoring Our Interaction Process
Wednesday, Week 6, Day 21, Jen, Josh, Stephanie, Rob, Wale, and Pivot John
We opened the night by discussing our upcoming talk in front of the LA Ruby meetup group tonight. Understandably, some of us who hadn't given presentations since college were a little nervous, so went went through some exercises to help us relax. Getting up on the stage where you needed to speak beforehand seemed like a great one; it would let you feel out the energy of the place first so when you go up for real it isnt a huge shock.
Testing our process
We then went through our Manual of Mob, reaffirmed which practices worked, which ones we had been straying from, and discussed if we needed to add new guidelines. WE talked about what hapens when we really get into a flow, how that state occurs, and what we can do to sustain it. For example, what happens when someone has a question but doesnt want to break the flow? Should they wait? If so, for how long? We deduced that our mobbing has naturally evolved to happen in three phases: a Q&A Phase where we figure out a general direction, a Tangent Phase where we examine the different ways of doing this, and a Driving Phase wherein we write the actual code. WE decided to Implement a "Pause before you Drive" rule. Give people a chance to ask any residual questions before you just go typing away.
Solutions through Ruby
When deciding Mobbing order, we usually write it on the whiteboard so that we're all on the same page. Naturally, as humans do, we sort of get into a patterned order of who drives who etc etc. To try to reduce this we wrote a little ruby shuffle program that just randomizes the order of all our names and spits out a little list. Much better and faster than drawing names out of a hat.
Once we established our order we started coding by writing tests to insure that some of our models had unique identifiers. What we had thought was unique before turned out not to be after we filled them with a bunch of sample data. We decided to give them a unique key that was based off of two other fields. This combination would be unique for every single one. Then we wrote tests that insured that we could look-up using that unique ID pair. This took us on a bit of a tangent regarding syntax in testing. There are a ton of different testing frameworks for Ruby out there, rspec, capybara, and cucumber just to name a few. All of these testing frameworks have different syntax but they're all based upon the idea of a fixed state box. We closed the night by talking about testing structure, Every test has the same basic structure, they
- A: Arrange a state.
- B: Act on that state.
- C: Assert what changed.
Once we truly understood this concept it opened up a whole new world to us.