C1

Slides originally by Lucas Zamprogno

What happened in C0?

You wrote tests for an existing implementation

What will happen in C1?

You will implement it yourself!
(And run your tests from C0 against your own implementation)

What's C1?

The Dataset Portion

  • You will be using an external package (JSZip) with a "real-world" level of documentation quality
     
  • Will involve promises
     
  • Getting an understanding of those two things is the bulk of the challenge

Examples:

"what departments have courses with averages higher than 90%?"

"What courses in CPSC have a high fail rate?"
 

Answer queries about UBC courses.

The Query Portion

{
   "WHERE":{
      "GT":{
         "courses_avg":97
      }
   },
   "OPTIONS":{
      "COLUMNS":[
         "courses_dept",
         "courses_avg"
      ],
      "ORDER":"courses_avg"
   }
}

{ result:
  [ { courses_dept: 'epse', courses_avg: 97.09 },
    { courses_dept: 'math', courses_avg: 97.09 },
    { courses_dept: 'math', courses_avg: 97.09 },
    { courses_dept: 'epse', courses_avg: 97.09 },
    { courses_dept: 'math', courses_avg: 97.25 },
    { courses_dept: 'math', courses_avg: 97.25 },
    { courses_dept: 'epse', courses_avg: 97.29 },
    { courses_dept: 'epse', courses_avg: 97.29 },
    { courses_dept: 'nurs', courses_avg: 97.33 },
    { courses_dept: 'nurs', courses_avg: 97.33 } 
  ] 
}

Answer queries about UBC courses.

The Query Portion

The Query Portion

  • Lots of navigating JSON objects and arrays
     
  • Will involve recursion
     
  • Can end up being a lot of code, it's a good idea to sketch out a plan beforehand to avoid confusion and spaghetti code

Now the "how"...

...

...

Query Engine

(recursion in practice)

{
   "WHERE":{
      "GT":{
         "courses_avg":97
      }
   },
   "OPTIONS":{
      "COLUMNS":[
         "courses_dept",
         "courses_avg"
      ],
      "ORDER":"courses_avg"
   }
}

Query handler

Query Engine

(recursion in practice)

{
   "WHERE":{
      "GT":{
         "courses_avg":97
      }
   },
   "OPTIONS":{
      "COLUMNS":[
         "courses_dept",
         "courses_avg"
      ],
      "ORDER":"courses_avg"
   }
}

Query handler

Body

handler

Options

handler

Query Engine

(recursion in practice)

{
   "WHERE":{
      "GT":{
         "courses_avg":97
      }
   },
   "OPTIONS":{
      "COLUMNS":[
         "courses_dept",
         "courses_avg"
      ],
      "ORDER":"courses_avg"
   }
}

Query handler

Body

handler

Options

handler

MComparison

SComparison

...

Query Engine

(recursion in practice)

{
   "WHERE":{
      "GT":{
         "courses_avg":97
      }
   },
   "OPTIONS":{
      "COLUMNS":[
         "courses_dept",
         "courses_avg"
      ],
      "ORDER":"courses_avg"
   }
}

Query handler

Body

handler

Options

handler

MComparison

SComparison

...

Planning and teamwork!

  • Take a slow read through of the spec, and make notes
    • You can even make // TODO notes in your code
       
  • Plan with your partner ahead of time on how you want to split work and coordinate
     
  • Some common approaches are
    • Splitting the work by dataset methods / perform query
    • Pair programming

Tips on splitting work

  • Issue: performQuery relies on the correct functioning of addDataset to produce results. Consider:
    • Fake adding a tiny dataset (mocking)
    • Query validation doesn't need a dataset
       
  • Issue: Interfering with each other's work. Consider:
    • Working in different files
    • Working in different branches
    • Coordinating responsibilities with git issues

This whole branch business

  • This term, we're enforcing some restrictions on branches to mimic some industry practices
  • When you merge to master, that's "releasing" to your client
  • Merging to master will require your partner's sign off
    • (Any teams of three only need one person)
  • Pushing directly to master is disabled, must by via pull request

This whole branch business

  • On master:
    • You get to see the public test suite in full
    • These commits are graded
    • These commits are subject to regressions
  • On other branches
    • You get to see some smoke tests
    • Commits not graded
    • Commits not subject to regressions

Regressions

  • When you release to your clients, you don't want to break stuff that works. They will be sad
    • Or worse, mad
  • If you break stuff that was once working, then that contributes to a penalty on the checkpoint/project
    • ("Breaking stuff" means a test went from passing to failing)
  • This is restricted to the "happy paths"
    • Only cases where the promise should resolve
    • Will be displayed as a cluster so it's easy to track

Tangent: Clusters

  • A cluster contains all directly related tests
     
  • A test can be in multiple clusters
     
  • Clusters with very low numbers of tests passing are a sign that this might be the cause of your trouble
     
  • Try and work off of your own tests as much as possible.
     
  • Have both simple and complex test cases

Miscellaneous Tips

Start early. Fail early.
Have enough time to fix things.

#1

(Also office hours get insane near deadlines)

#2

TDD and testing can help you break down the high level goals -- addDataset(), performQuery() -- into smaller, easily testable tasks: saveDatasetToDisk(), validateQuery().

Write these tests first, make sure they fail, then write the code to make them pass

Use TDD

Make use of your debugger and logging from the beginning!

#3

#4

When you're stuck:

- Get away from the computer

- Take a walk

- Drink some coffee

- Get some sleep

- Do whatever brings you joy

- Make use of labs and office hours

#5

Keep communicating with your teammate, always. Communication is key.

#6

Finally...

Please start early!!!

Questions?

Made with Slides.com