on master help sign in
split up todo/readme
88ab688Mark Wotton
README.md−33
@@ -48,36 +48,3 @@ there's a lot of the state space you just can't explore without context: modern
48full of pointer-like structures, whether they're URLs or database
48full of pointer-like structures, whether they're URLs or database
49keys/uuids, and servant-quickcheck requires that you be able to generate
49keys/uuids, and servant-quickcheck requires that you be able to generate
50these without context via Arbitrary.
50these without context via Arbitrary.
51−
52−## extensions/todo
53−
54−- add some "starter" values to the store
55− - there may be a JWT that's established outside the servant app, for instance.
56−- `class Extras a where extras :: Gen [a]`
57− - default implementation `pure []`
58− - selectively allow some types to create values we haven't seen from the api.
59− `newtype FirstName = FirstName Text`, say.
60−- break down each response type into its components
61− - if i have
62− - `data Foo = FBar Bar | FBaz Baz`
63− - an endpoint `foo` that returns a `Foo`
64− - and an endpoint `bar` that takes a `Bar`
65− - I should be able to call `foo` to get a `Foo`, and if it happens to be an `FBar Bar`, I
66− should be able to use that `Bar` to call `bar`.
67−- better handling of properties to be verified
68− - some properties should always hold (no 500s): this already works.
69− - to-do: there may be some other properties that hold contextually
70− - healthcheck should be 200
71− - test complex permissions/ownership/delegation logic - should never be able to
72− get access to something you don't own or haven't been delegated access to.
73−
74−## other possible applications
75−
76−- coverage
77− - if you run the checker for a while and `hpc` suggests you still have bad coverage,
78− your api is designed in a way that requires external manipulation and may be improvable.
79−
80−- benchmarking
81− - we can generate "big-enough" call sequences, then save the database & a sample call for each
82− endpoint that takes long enough to be a reasonable test.
83− - from this we can generate tests that a given call on that setup never gets slower.
TODO.md+32−8
@@ -1,8 +1,32 @@
1−DONE
1+## extensions/todo
2−- basic setup
2+
3−- extract response types from the api
3+- add some "starter" values to the store
4−- proper readme
4+ - there may be a JWT that's established outside the servant app, for instance.
5−
5+- `class Extras a where extras :: Gen [a]`
6−TODO
6+ - default implementation `pure []`
7−- some way to select a random endpoint to run from a given Server.
7+ - selectively allow some types to create values we haven't seen from the api.
8−- hook up quickcheck-state-machine/hedgehog
8+ `newtype FirstName = FirstName Text`, say.
9+- break down each response type into its components
10+ - if i have
11+ - `data Foo = FBar Bar | FBaz Baz`
12+ - an endpoint `foo` that returns a `Foo`
13+ - and an endpoint `bar` that takes a `Bar`
14+ - I should be able to call `foo` to get a `Foo`, and if it happens to be an `FBar Bar`, I
15+ should be able to use that `Bar` to call `bar`.
16+- better handling of properties to be verified
17+ - some properties should always hold (no 500s): this already works.
18+ - to-do: there may be some other properties that hold contextually
19+ - healthcheck should be 200
20+ - test complex permissions/ownership/delegation logic - should never be able to
21+ get access to something you don't own or haven't been delegated access to.
22+
23+## other possible applications
24+
25+- coverage
26+ - if you run the checker for a while and `hpc` suggests you still have bad coverage,
27+ your api is designed in a way that requires external manipulation and may be improvable.
28+
29+- benchmarking
30+ - we can generate "big-enough" call sequences, then save the database & a sample call for each
31+ endpoint that takes long enough to be a reasonable test.
32+ - from this we can generate tests that a given call on that setup never gets slower.