C1

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

The Query Portion

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"...

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

#1

(Also office hours get insane near deadlines)

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

#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...

Questions?