Virtual Mini-sprint: GEIS, TDD, and Peer-review
One of the most natural fits for TDD is API development since one is often working directly from a spec in that case. Let's face it, specs are just a step (or two) removed from unit tests :-) GEIS is thus a perfect first project for our TDD efforts, and we can use this opportunity to all practice together.
The intended end results will be the following:
* we all are on the same page (almost literally) when it comes to development process
* that we will all have worked together on a single project as a whole
* we will have a solid introduction to creating unit tests
* developing implementation code from unit tests
* ensuring error checking/conditions are present in code
* ensuring test coverage exists for all logic branches in the code
* that we all know how to review a code change/branch
* that we establish habits of compiling, checking output, checking for functionality of binary
* we run the test suite(s) as part of the review process
* we will have a completed, fully functional GEIS API
The first step will be a spec review. Then we'll jump into the code.
We will start together on the spec that Stephen created for us... one that got *very little* initial feedback. EVERYONE will read this and make comments in a dedicated ticket I will create for this task.
Then, we will start on actual coding. I will be splitting the code base into 5-6 arbitrary chunks for review, analysis, discussion, unit tests, implementation, peer review, adjustments, sign-off, and merge. Each chunk will get a "feature" ticket created for it, and a lead assigned to it. The leads for each ticket will be comprised of the core MT team members I'm hoping to have for Natty Narwhal (Stephen, Ikbel, Cody, Ted, and Chase).
We'll all be working on a single ticket at a time -- uTouch team members (and other who want to participate) will perform a review and will discuss current implementation, ask questions, propose solutions, etc., on IRC, on the ticket comments, or on the mail list. At which
point, a new branch will be created by the first lead, and that person will work on an implementation.
For those who don't feel they have enough technical background to take the lead, they will still take the lead! However, we can set up pairing sessions (skype, screen, remote server, etc.) to address this. We'll all work together to make it happen.
Next, we'll step through the peer-review process together when the implementation's merge is proposed. For this, we will follow the guidelines as outlined here:
https:/
We will progress through the remaining tickets in the same fashion, with a different person taking the lead for each one.
When we're done, we will not only be masters of TDD and peer-review, but we will have a fully completed GEIS implementation too :-)
And remember: Don't Panic.
Blueprint information
- Status:
- Complete
- Approver:
- Duncan McGreggor
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Duncan McGreggor
- Definition:
- Approved
- Series goal:
- None
- Implementation:
- Implemented
- Milestone target:
- None
- Started by
- Duncan McGreggor
- Completed by
- Stephen M. Webb
Whiteboard
We never ended up doing this formally, but we did work on much of this throughout the cycle.