User:Ctalbert:Automation Summit

From MozillaWiki
Jump to: navigation, search

Preparation

Existing Documents

Documents we want

  • Overview of XPCOM, interfaces and how XPCShell helps us to test that.
    • Use Overview 1 and Overview 2 from above
  • Overview of the necessary Javascript
  • Include a sample test, and talk about each step as it is built
    • Use Anything we need (and link to as necessary) the Javascript guides and references above.
    • Use the Using XPCOM Components document to emphasize how to create these tests
  • Something about how to integrate your newly made test into the makefile
    • deal with spaces tab question
  • Now that you've written it - getting it reviewed
    • Have a style checklist
    • Talk about bugzilla and requesting a review
    • List reviewers
  • Automation topics
    • How to test for buffer overruns
    • How to think about automated testing/regression testing
    • How to do negative testing with NULL values
    • How to do think about using the APIs in different ways
    • How to create Wicked recurrence Rules
      • ICS Recurrence
  • Test Topics
    • Testing a la 2445 - how to create test cases based on iCalendar Rules from the RFC 2445
    • Testing with providers
    • Testing for memory leaks
    • Testing with iTIP RFC 2446
    • Testing with Timezones
    • Testing for sql injection with SQLite
    • Testing the storage provider
    • Testing offline
    • Testing Sync
    • Testing the Javascript based objects
    • Testing the views

I'm not sure each of thes bullet points will be a separate document. I'd like to hear some ideas on what should be spearate documents, and what parts of existing documents to reuse

Open Questions

  • How much of the existing documents can we reuse by reworking into a more user-friendly format
  • How do we give all the stuff we're doing back to MDC for inclusion in their content? Or should it be linked off some main QA/Automation page on the wiki?
  • How long should each document be? I don't want the "interminable scrolling" experience of reading these things.
  • For the sessions that are not calendar specific, should we get speakers from outside the project to either moderate or present? The best example of this would be the automation/unit test/regression test/ philosophy talk?
    • This would really help with publicity, and give even more people a reason to come.
    • Could we get some well known author of a well-known software testing book?
    • Any ideas on who such a person might be?

Publicity

For the event

  • Emphasize that this will teach you the basics of Mozilla Hacking and it is more applicable than simply unit testing. This is just an easy place to start were you can make an immediate contribution.
  • Blog, NG, Mozzine Forums, Targetted Publicity
  • Cross post to developer newsgroups, other product newsgroups? Ask other products to help us promote?
  • Actual Press Releases? I should call in the reporter that got us on Slashdot

Why should I come to the event?

  • Prepares you for working on any project built atop the mozilla platform TODO: get the number of projects on the platform - in the hundreds if not thousands
  • Gives you an easy way to get started in any of those projects - unit/regression tests are generally always needed, and always appreciated.
  • It's easier to get started with unit/tests because they are easier to review and smaller codebase, rather than compiling a patch or an extension which are usually more longer term processes
  • Resume building

Why Should I help prepare the event

  • The very best way to learn something is to teach it.
  • This is going to be an absolutely high quality, kick a$$ event. If it were done in a physical place, I'd be inviting speakers from all over the spectrum, and I'd be having it at the Ritz-Carlton or some other such 10 star hotel.
  • It's going to be a whole lot of fun preparing it and pulling it off.
  • We're going to be a part of the future of the Mozilla Community. When this works for us, other projects will pick it up and do similar things.
  • We're enabling people to do things that they've been wanting to do, teaching people like that is always rewarding
  • It's going to bring in a lot of new volunteers to the calendar project, most of whom will move on, but a few of whom will stay.
  • It'd be a great resume builder.
  • No one's ever done it before (to my knowledge) :-)

Structure of Event

Session 1 The How-To

  • It's going to be a little bit lecture style where we actually walk through that tutorial that we built in the documents but do it in real time with commentary about each step.
  • Use pastebin to show the code as we complete our test
  • Talk about the ins and outs of the JS language
  • Talk about how the XPCOM and XPConnect factor into this
  • Run the test and pastebin the output.
  • Invite questions

Session 2 About Unit/Regression/Automated Testing

  • Discuss philosophy behind it.
  • Talk about how the tests catch bugs
  • Talk about what makes a "good" test
  • Discuss general questions

Session 3 iCalendar

  • Discuss the high levels of iCalendar syntax
  • Discuss how to test per the specification
  • Create a sample test that does this

Session 4 Provider Testing

  • Create sample test for provider
  • Discuss the ins and outs of the listener interfaces
  • Discuss the various ideas surrounding the provider testing

Session 5 The JS language

  • Discuss the interesting points and basics of high level JS
  • Discuss the JS Object
  • Discuss the XPConnect interfaces (Cc, Ci, Cr etc)
  • Discuss dump
  • Discuss Venkman (or is that overkill?)
  • Discuss interfaces themselves - philosophy and how to code to an interface

Notes

  • Is this the right order? I'm just numbering as they come to mind
    • TODO: Vet the order
  • How many sessions? Probably no more than five, maybe only 4.
  • Should we do two a day? One after "working hours" in Europe, the other after "working hours" in the states? Or is one a day sufficient? Might be better to do one a day so that people are forced to concentrate and come to them.
    • Need direction to decide this. Maybe we will know what to do once we have an idea of how much interest there is?


Guidelines

  • Keep all sessions to an hour
  • Practice it - have the code written, have the pastebins in tabs showing each step and ready to go so all you have to do is click "submit" as you "finish" each step
  • Know what we'll cover and when. Let people ask questions, but don't let people derail it.
  • Think "cooking show" style
  • Do it in our "normal" calendar-qa channel, so that people get used to having one location to find us.
  • Different moderators/presenters for each session?
  • Should the sessions be on different days of the same week?
    • Monday session 1
    • Tuesday session 2
    • etc
    • Keep them at the same time each day
  • Log all sessions so that people can easily read them later and we can use them as training materials in the future.
Retrieved from "https://wiki.mozilla.org/index.php?title=User:Ctalbert:Automation_Summit&oldid=74702"