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
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"...
...
Planning and teamwork!
- Take a slow read through of the spec, and make notes
- You can even make // TODO notes in your code
- 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