Tests should tell a story, and not be some complicated array of technical terms that almost nobody understands. This is our focus during the next <\/span>#RemotePairProgramming<\/span><\/span><\/a> session with Bastien David. <\/span><\/p>\n We call our tests paragraphs and our test class a story. Because we feel in a flow, we could go on writing tests that tell a story for a few hours and still discover what it an easy to understand story by the end user: the programmer.<\/span><\/p>\n <\/p>\n Involve concepts of user experience in programming, and consider the programmer to be the user of the program and the tests. Think deeply about how to name your tests, how easy they are to understand, what is the order of the tests so it makes sense. We want the readers to easily immerse themselves into the story and be captivated as easy as possible. Anything that one doesn’t understand is not in it’s place. So we review, improve, revise, improve, review, improve until everything looks fine. And then we review and improve again. There is an iterative process of improvement that happens with tests that tell a story, when you really care about your users.<\/p>\n During this episode we have a balanced pair programming approach, where both of us contribute, as compared to Strong Style Pairing<\/a>.<\/p>\n Pair programming is a technique in which two programmers work together to solve a task. They work on one computer, ideally each having their own keyboard in front of them. The driver writes the code and takes the short time decisions. The driver should trust the navigator totally for the long term decisions.<\/p>\n Check the full video next week.<\/p>\n
\nThere are two roles: driver<\/strong> and navigator<\/strong>.<\/p>\nVideo<\/h2>\n