Readings

• #19: Code maintenance and refactoring
  McConnell, Code Complete, Ch. 24: Refactoring
  (another enjoyable read: How to Write Unmaintainable Code)
• #18: Code reviews, walkthroughs, pair programming
  McConnell, Code Complete, Ch. 21: Collaborative Construction

  (Choose either to read and summarize #18 for Wed Mar 5, OR read and summarize #19 for Fri Mar 7.)

• #17: Security Testing 2
  Andrews/Whitaker, How to Break Web Software, Ch. 5: Attacking User-supplied Input Data
  (if you enjoy this topic, you may also want to read Chapter 4 as background)
• #16: Security Testing 1
  Andrews/Whitaker, How to Break Web Software, Ch. 3: Attacking the Client
  (if you enjoy this topic, you may also want to read Chapter 2 as background)

  (Choose either to read and summarize #16 for Wed Feb 27, OR read and summarize #17 for Fri Feb 29.)

• #15: Integration Testing
  McConnell, Code Complete, Ch. 29: Integration
• #14: Automation / Acceptance Testing

  Your assignment: Familiarize yourself with Selenium or an equivalent automation tool, and summarize your findings about it. You might want to read the Wikipedia page about Selenium for some basic background information. Below are some suggested readings:

  • Tutorials: Selenium IDE intro, Selenium RC Tutorial, Selenium Demo
  • Videos: Selenium in action, Google Video by the author (start about 8 minutes in!), Selenium the movie
  • Selenium and Ajax: Link 1, Link 2, video 1, video 2
  • Selenium and ASP.NET: Automated Testing of ASP.NET web applications using Selenium

  You don't have to read about Selenium. Here are some other system/automation testing tools and information:

  • FIT testing tool: Homepage; Acceptance Testing Using FIT; FitRunner Eclipse plugin
  • Ruby on Rails: A Guide to Testing the Rails, Ch. 9: Testing Your Controllers
• #13: Unit testing
  

  Your assignment: Read one or more documents (one or more bullets from the lists above) about your project's language, or choose your own document, print it out, and turn in your printout along with a summary of it; summary due Fri 2/15.

  Java (JUnit):
  • Vogel, Java Unit testing with JUnit 4.x in Eclipse
  • Goncalves, Get Acquainted with JUnit 4 ( PDF version)
  • Stuckert, JUnit Reloaded (tells differences between JUnit 4 and previous versions)
  Ruby (Test::Unit):
  • Kellock/Carter, A Guide to Testing the Rails, Chapters 2 (Test/Unit), 5 (assertions), 8 (modules)
  • Module Test::Unit Documentation
  .NET (NUnit):
  • Samuel, NUnit: A Tutorial
  • NUnit.org, Getting Started with NUnit
  • Gehtland, Testing ASP.NET Applications with NUnitASP and NUnit
• #12: Testing
  McConnell, Code Complete, Ch. 22: Developer Testing (summary due Mon 2/11)
• #11: Programming by contract (preconditions, postconditions, assertions)
  Horstmann, Object-Oriented Design and Patterns, Ch. 3: Programming by Contract
• #10: Web design patterns
  
  • van Welie, Patterns in Interaction Design
  • Kerievsky/Pryce/Rees/Brown, Website Patterns
  (Read ≥ 12 total patterns from the two sites, then summarize 6 patterns.)
• #9: Design patterns
  Horstmann, Object-Oriented Design and Patterns, Ch. 5: Patterns and GUI Programming
• #8: UML sequence diagrams
  Fowler, UML Distilled, Ch. 4: Sequence Diagrams
• #7: UML class diagrams
  Fowler, UML Distilled, Ch. 3: Class Diagrams
• #6: Object-oriented design
  Riel, Object-Oriented Design Heuristics, Ch. 3: Topologies
• #5: Paper UI prototyping
  • Snyder, Paper Prototyping ( HTML version)
  • Klee, Five Paper Prototyping Tips ( HTML version)
• #4: Working in teams
  • McConnell, Rapid Development, Ch. 13: Team Structure
    (you can skip the gray "case study" sections)
  • Hunt/Thomas, Pragmatic Programmer, Ch. 8: Pragmatic Teams
• #3: UML use cases
  Cockburn, Writing Effective Use Cases, Ch. 1
• #2: Getting started on a software project
  Hunt/Thomas, Pragmatic Programmer, Ch. 7: Before the Project
• #1: Software lifecycle models
  McConnell, Rapid Development, Ch. 7: Lifecycle Planning

• [1/27] Some clarifications about summaries: Summaries are due at the start of lecture. A few minutes into class, we'll stop accepting them. Any student who brings a late summary will receive 0 points.

  Also, we have seen some common mistakes in the summaries we have been grading. We've documented these in the sample summary document linked from the first day of lecture. You may want to take a look at them.

  Our intention is that the summaries should not take very long or cause much stress. If you summarize a handful of the main points from the article and provide a bit of critical analysis, you should get your 4 points.