This week's sessions will focus on TDD from the "middle" of the system. (True "top-down" would be from the UI, but we'll save that for a later session.)
We will test drive a set of rules from the controller (a stand-in for a portlet), and create the database interactions as we go. The idea is to set the expectations for what we want the database to do first, then implement the appropriate DAO and SQL.
The intent is to practice doing TDD the right way, while picking up tips and tricks from each other's experience.
This exercise features:
We'll do something simple, but close enough to the real-world to be effective. To keep it simple, we will use an existing table from Career Transitions, which contains information about careers. Career data is organized into a hierarchy with career "clusters" at the top, a set of "pathways" within each cluster, and a set of careers within each pathway. All of this data is stored in the CT_CAREERS table.
The concept is that the user can drill down through a tree of cluster->pathway->career, viewing an alphabetically sorted list of each at all three levels.
We will implement the following rules:
Curriculum topics covered
These sessions will cover all of the "foundation" TDD topics in our curriculum:
The curriculum mind-map is here. You can download a copy of XMind here.
The exercise code. (Requires the CT database to run.)
Why top-down testing & design?
Post-Retrospective, Aaron, Drew and a person whose name I don't know (sorry, I should have asked) stuck around to help come up with the problem for the next Randori. It is a real business problem that Aaron's team is solving...
When we retrieve date ranges from Ocean, they look like this:
"120010102-120110304"They must be formatted to something like:
"1/2/2001 - 3/4/2011"Rules for edge cases:
Randori Sessions >