Notes Index
Extreme Programming
Review from CS 351
eXtreme Programming (XP) is one of the emerging Agile Programming methodologies serving as a middle ground between programming as chaos and programming as an engineered activity. The key strength of extreme programming is its simplicity, team work, quality control, and testing.
XP Values
XP core values are Simplicity, Communication, Feedback and Courage.
As Kent Beck says: "Do more of what works and do less of what doesn't"
As Ron Jeffreis says: "You're not gonna need it"
- Simplicity encourages
- Delivering the simplest functionality that meets business needs
- Designing the simplest software that supports the needed functionality
- Building for today and not for tomorrow
- Writing code that is easy to read, understand, maintain, and modify
- Communication is accomplished by
- Collaborative workspaces
- Co-location of development and business space
- Paired development
- Frequently changing pair partners
- Frequently changing role assignments
- Public displays of status
- Short Scrum meetings
- Unit tests, demos, and oral communication, not documentation
- Feedback is provided by
- Aggressive iterative and incremental releases
- Frequent releases to end users
- Co-location with end users
- Automated unit tests
- Automated functional tests
- Do the right thing in the face of opposition
- Do the practices required to succeed
Core Practices of XP
Extreme programming was developed as a methodology for producing software. As the Web is transitioning from static pages to dynamic applications, XP is increasing being applied to Web development as well.
As originally defined, there are twelve core practices to XP:
- The Planning Game: Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
- Small releases: Put a simple system into production quickly, then release new versions on a very short cycle.
- Metaphor: Guide all development with a simple shared story of how the whole system works.
- Simple design: The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
- Testing: Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. This has become known as Test-Driven Development.
- Refactoring: Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.
- Pair programming: All production code is written with two programmers at one machine, one keyboard, and one mouse.
- Collective ownership: Anyone can change any code anywhere in the system at any time.
- Continuous integration: Integrate and build the system many times a day, every time a task is completed.
- 40 hour week: Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
- On-site customer: Include a real, live user on the team, available full-time to answer questions.
- Coding standards: Programmers write all code in accordance with rules emphasizing communication through the code.
The twelve core practices have evolved into simple rules for XP
Pair Programming
With eXtreme Programming, every line of code is written by two people, working side-by-side, collaborating on the same design, algorithm, code or test. This practice is called pair programming.
- One programmer (the driver) has control of the keyboard/mouse and actively implements the program.
- The other programmer (the navigator) continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work.
The driver and the navigator communicate, if only through grunts (as in, "Huh?"), at least every 45 to 60 seconds. It is important to switch roles periodically between the driver and the navigator.
Software Tools for Extreme Programming
Two common tools used with Extreme Programming are version control and unit testing software. The Hebeler labs have installed TortoiseSVN for version control and NUnit for unit testing.
New to Visual Studio 2008 Professional is a built-in unit testing tool.
Version Control
Version control software allows teams of programmers to work together on a software project and merge changes to a common repository of code. Subversion is an open source version control tool used by many on a variety of platforms.
TortoiseSVN is a Windows based front-end to Subversion. It is installed on the lab computers and accessible from a right-click inside My Computer.
Project files are stored inside a Subversion repository. During development, the files are checked-out, modified and added to, thoroughly tested, and then merged back into the repository so others have access to them.
A quick tutorial for Using Subversion with TortoiseSVN will get you going.
For a review of setting up a repository see CS 351 Day 36 notes
Test-Driven Development
Unit testing is the testing of individual class methods. This can be tedious to perform without testing tools.
Test Driven Development (TDD), also known as "test-first programming" can be summarized as test twice, code once
- Write a unit test for a new method and see it fail.
- Write the new method, doing "the simplest thing that could possibly work."
- See the test succeed, and then refactor the code.
Test Frameworks
Test frameworks are unit testing software tools used to enable TDD.
There are a lot of testing frameworks available, many of which are open source (see TestingFramework wiki). The most famous testing framework for Java developers is JUnit. JUnit served as the inspiration for many other testing frameworks including NUnit, a unit-testing framework for all the .Net languages.
Unit testing is typically done on the business logic and data access methods. User interface testing requires a different set of tools, or is quite often done manually.
We will use a MS simple layer and data access layer for access a Microsoft Access Database for today's session
Hands-on Exercise 1
- Create a Day26 web site with Visual Studio
- Add a new project: Windows Class Library to your solution
- Download the 5 files to your U: drive
- Add the
Customers.mdb database file into the App_Data folder of your website
- Add the C# source files to your class library
We will use Visual Studio's Unit Test Wizard to help unit test the data access methods
- From the Test menu, select New Test
- Select Unit Test Wizard C# test project, click OK
- Expand the CustomerDataAccessLayer class and select getConnection(), click OK
- Build your project and eliminate any compiler errors
- Use the Test Menu to Run All Tests in the Solution
