Developer Camp - April 2009 (San Francisco)

The Location of the Event has been changed to the Mitch Kapor Foundation

Goals for Developer Camp

Please add a few things you want to accomplish at Developer Camp. This will help us tailor the camp to your needs. You can either edit the agenda or add your goals as a comment.

Things to do before Camp (Prerequisites)

All attendees are expected to be fairly savvy with CiviCRM (from a user/admin perspective) and have a good idea of the CiviCRM schema.

• Each attendee is minimally expected to bring a laptop which has a working copy of CiviCRM 2.2.2 installed on it.

• If you can, please install CiviCRM from svn (http://wiki.civicrm.org/confluence/display/CRMDOC/Installing+CiviCRM+from+subversion+(SVN)+repository)

• Understanding CiviCRM internals would be nice but not essential. Please spend some time reading the Architecture Series

• PHP/MySQL expertise is a must.

• If you have any problems with any of the above please contact us via email or irc

Pre-Camp Dinner Meeting

A dinner is scheduled at Ton Kiang for Tuesday April 28th at 7:30 pm. This will be a no-host dinner. We expect the dinner to cost approx $40. There is public transportation along Geary St from downtown. Please send us an email (lobo at civicrm dot org) if you can make this event.

Camp Location

Mitchell Kapor Foundation
543 Howard Street, 5th Floor
San Francisco, CA, 94105
Map this Location

CiviCRM Testing (led by Walt Haas)

• Why do we test?
  • It is not yet possible to prove correctness for a non-trivial program
  • Therefore testing remains as the only way to "prove" program correctness
  • Buggy code is expensive - DharmaTech spent 57.5 man hours on the duplicate membership bug.
  • Tests are the best documentation of how to use the software being tested
  • Verify that a change to an existing program didn't break anything
  • Save time (yes really)
• What kinds of tests are useful?
  • "Eat your own dogfood"  At DharmaTech we use the same software we deliver to clients, and we use it before they do.
    • Pros:
      • Realistic since we use it the way the client does
    • Cons:
      • Not guaranteed to test every function, since we don't use every function
      • Our experienced people don't look at the UI the same way a first-time user would
  • Unit tests
    • Pros:
      • Easy to write
      • Run fast, it's possible to check every change immediately
      • Possible to check unusual error conditions such as database failures
    • Cons:
      • Doesn't check module interaction bugs like this one
  • Integration tests
    • Pros:
      • Find problems of module interaction not found by unit tests
    • Cons:
      • Slow execution
  • Regression tests
    • Any tests, unit or integration, that assure that existing functions aren't broken by a change
• What tools can we use?
  • Simpletest (PHP unit tests)
    • Runs on PHP command line
  • PHPUnit (PHP unit tests)
    • Runs on PHP command line
    • Works with XDebug to generate code coverage reports
    • Actively developed
  • JsUnit (JavaScript unit tests)
  • Selenium (browser level)
    • Runs in the browser, so it sees the same thing the user does
    • Runs in the JavaScript sandbox; therefore it cannot upload a file or reference a site that it was not loaded from (can't go between http://example.com and https://example.com)
    • Runs on recent browsers
    • Programmed in HTML
    • Very simple language with no if-then-else, function call or iteration
  • Molybdenum (browser level)
    • Runs in the browser, so it sees the same thing the user does
    • Firefox plugin, so it can upload a file from your computer and reference any site
    • Started as port of Selenium core to a plugin
    • Actively developed
    • Programmed in XML
    • Extensions (relative to Selenium) are being developed
• How do we get the community to help build tests.
• How do we "force" the core team to be more "religious" with regard to this

Projects for Code Sprints

• CiviGrant - support for BOTH grant directions (grants given out and grants applied for/received). See draft spec by Eileen here. (led by Eileen)

• Drupal Calendar <-> CiviEvent and/or CiviCRM Activities integration +1

• Advanced Views2 Integration

• CCK Integration

• Custom Search: Build a custom search based on needs of developer camp attendees +1

• CiviReport: Build a report template based on needs of developer camp attendees +1
• Better managing households in CiviCRM (Tony of DT)

• Development Environments - best practice for ensuring that improvements are included in core (i.e. hardware set up, using jira best practice etc. for bug fixes and minor feature requests)

• Improvements to how orgs and individuals are modeled wrt. viewing contacts, searching and reporting, using associated profiles

• Improvements resulting from deploying CiviCRM on civicrm.org
  • CRM-4398:Send Email to Contacts - Allow CC and BCC
  • Build CCK / Views interface to collect data and reviews on Hosting Providers
  • Build page to collect information on developers and civicrm customers via profiles (see EU/Int teleconference)
  • Build Donation Page for civicrm.org