Difference between revisions of "Coaching Environment - TDD"

(New page: == Contact Information == Craig Larman, craig@craiglarman.com. +1 214 914 7593 == Room, Walls, Whiteboards == * People will be organized into table-teams, averaging 5 or 6 people per tea...)
 
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Contact Information ==
+
== Timing ==
Craig Larman, craig@craiglarman.com. +1 214 914 7593
+
I've noticed over the years that if i arrive at a site for this coaching at 9 am, and people start setting up the environment described below at 9 am, it can take 30-60 minutes of fussing around to get things ready. Therefore, please *COMPLETE* ALL of this the day ''BEFORE''.
  
 +
 +
== Context, People ==
 +
While working on the real (usually messy legacy) code, coach developers in how to break dependencies, test in isolation, and do TDD.
 +
 +
2-7 developers, plus coach.
  
 
== Room, Walls, Whiteboards ==
 
== Room, Walls, Whiteboards ==
* People will be organized into table-teams, averaging 5 or 6 people per team. Thus, we need  NumStudents/5 tables; e.g., 6 or 7 tables if 35 students. The tables are ideally in separate islands, circular or square, with a team at each.
+
* 1 projector & screen
 
 
* Don’t make it a crowded room; there are a number of exercises that involve the teams moving around.
 
  
* There are several wall exercises, involving flip chart paper or PostIt Note layouts; each team needs some unencumbered clear wall space for this.
+
* 1 computer, connected to the production code and development tools
  
 +
* 1 whiteboard
  
== Supplies for the Coach/Speaker  ==
+
* 1 flip chart paper
Read this: [[Supplies - for Coach Use]]
 
  
 +
* 1 tape (e.g., masking tape), unless the flip charts of PostIt flip charts with sticky back
  
== Table Layout ==
+
* WHITEBOARD marker pens
* Round tables are ideal
 
  
* Tables should not be against the walls; we are using the walls as a main working area in this course.
+
* whiteboard eraser
  
* Distribute the tables throughout the room
+
== Choice of Legacy Application and First Method to "Bring Under Test" ==
 +
We should start on an method or function that that you would like to "bring under test" -- to be able to unit test in isolation, so that we can do unit TDD. The method should NOT be trivially easy -- it should have some dependency problems, because teaching dependency breaking is a point of the coaching. On the other hand, it should not be the most awkward, messy, highly dependent method you can think of -- that would make getting started too slow.
  
  
 
== Computers, Software and Networking ==
 
== Computers, Software and Networking ==
* There are a few short exercises on spreadsheets. These are team exercises (average 5 persons per team). Thus, at least one laptop is required for each team; two is nicer. Therefore, ask people to bring a laptop if they have one.
+
* 1 fast computer connected to the real product software, with internal network and internet access.
 
 
* A power supply is NOT needed for each table, because the computer use is minimal. However, please ensure there are some powerstrips “somewhere” in the room so students can recharge laptops.
 
 
 
* No network is required.  
 
 
 
 
 
== Other Supplies for Student Use ==
 
Read this: [[Supplies - Creativity Tools]]
 
  
 +
* access to the production source code of your entire product
  
== Pictures of Classroom Setup ==
+
* access to all the usual development tools that are used: editors, IDE, version control, ... (since we will be working on regular product code)
[[Image:Csm1.jpg | 680px| ]]
 
  
[[Image:Csm2.jpg | 680px| ]]
+
* NB!! pre-installation of the chosen TDD framework (JUnit, NUnit, BoostTest, ...). ACTION >> Check with the coach with framework to install, and prepare this before the coaching session.

Latest revision as of 21:10, 21 June 2015

Timing

I've noticed over the years that if i arrive at a site for this coaching at 9 am, and people start setting up the environment described below at 9 am, it can take 30-60 minutes of fussing around to get things ready. Therefore, please *COMPLETE* ALL of this the day BEFORE.


Context, People

While working on the real (usually messy legacy) code, coach developers in how to break dependencies, test in isolation, and do TDD.

2-7 developers, plus coach.

Room, Walls, Whiteboards

  • 1 projector & screen
  • 1 computer, connected to the production code and development tools
  • 1 whiteboard
  • 1 flip chart paper
  • 1 tape (e.g., masking tape), unless the flip charts of PostIt flip charts with sticky back
  • WHITEBOARD marker pens
  • whiteboard eraser

Choice of Legacy Application and First Method to "Bring Under Test"

We should start on an method or function that that you would like to "bring under test" -- to be able to unit test in isolation, so that we can do unit TDD. The method should NOT be trivially easy -- it should have some dependency problems, because teaching dependency breaking is a point of the coaching. On the other hand, it should not be the most awkward, messy, highly dependent method you can think of -- that would make getting started too slow.


Computers, Software and Networking

  • 1 fast computer connected to the real product software, with internal network and internet access.
  • access to the production source code of your entire product
  • access to all the usual development tools that are used: editors, IDE, version control, ... (since we will be working on regular product code)
  • NB!! pre-installation of the chosen TDD framework (JUnit, NUnit, BoostTest, ...). ACTION >> Check with the coach with framework to install, and prepare this before the coaching session.