- Recap of QuickCheck
- Context of the paper
- Trying it out
- Techniques used in QuickerCheck
- Evaluation
- Related work
- Conclusion and Future
- Questions
<h2>Recap of QuickCheck</h2>
Use to check your program. You can specify conditions your program should comply to and QuickQheck will generate a test that checks if the condition holds. For example a condition of reverse is: reverse (reverse xs) == xs. Unfortunately this condition on its own this is not enough, because const will also comply.
<h2>Context of the paper</h2>
The idea of QuickerCheck is that it uses multiple cores.
<h2>Trying it out</h2>
We see that the total time (so across threads) the time is much longer. But in real time there there is a performance increase. There are some conditions for using QuickerCheck: make sure the code is thread-safe.
<h2>Techniques used in QuickerCheck</h2>
It has has hard to make, because QuickCheck does not lend itself to parallelism. Test shrinking happens when there is a failing test, it makes the test smaller such that it does not fail. It is better than.

If one of the treads finishes, because the test case is not valid. It has to report this to main thread to let it know to the user and terminate all other threads. 

Test shrinking means finding a failure and reducing it to the smallest failure, so it is easier for the user to read. Imagine there is a big input that fails, then smaller parts of the input are tested for failure. 
<h2>Evaluation</h2>
How do we know it is faster? They did this with benchmarks. The saw that the number of speedup goes up with more cores.
<h2>Related work</h2>
For other languages there are also check libraries. fsCheck for .Net code also has parallelism and uses strides. tasty for Haskell has parallelism support, but only inside
<h2>Conclusion and future</h2>
It is mainly beneficial for slow properties, but shrinking not always. In the future they want to use faster algorithms.
<h2>Questions</h2>
What if a property is already parallel?: It will probably be problematic