Trophies in storybook

[MarlonWelter]

This issue is related to #54

The Problem
When creating new trophies, it would be great to have a simple way to check, if the new trophy can be achieved or if it is throwing some error. It would be nice to have it in the storybook.

The Idea
Add a few sample matches to TrophyHunter and create a new story for each trophy. In each story the extendMatchResults code will be called and after that individually the important data for that trophy will be shown.

example
For example for the trophy hextechLord (earn 15000 gold), the data on a test with three matches could look like this:
data = [ { goldEarned: 12345, achieved: no }, { goldEarned: 23456, achieved: yes}, { goldEarned: 14999, achieved: no }].

[lmachens]

Storybook is more for UI tests and not unit tests. You can already find the trophies page in storybook.
We can use Jest for the test cases you described.

The hextechLord example is easy to implement, but what about more complex trophies where we use the timeline?
If we want to know if a trophy is still obtainable after we changed the api or extendMatchResults, we could simplify the tests.
My idea is to only save two matchIds for every trophy. One for obtained, the other for not obtained.
The unit test could fetch the match from our api and test if it is still obtainable.
This would make simplify the testing and there is no need to hard code match data.
Hard coded matches takes a lot of time to add. If riot decides to change the schema, we have to update all matches by hand.

But there is adownside with unit tests which fetches the matches. Tests runners takes more time and it is required that the api is online. But I think the advantages are stronger.
Wdyt?

[MarlonWelter]

summary of what we spoke about yesterday

idea
instead of adding something to storybook, we add a method in the api endpoints.
This method does the following:
On a small set of matches (manually picked for now, not connected to the database) it calls extendMatchResult on these matches and then returns the extendedMatchResult objects. Because this way it is not connected to our database, it might be a good possibility for future developers to test new trophies.

use-case
This is intended as a simple way to check if the stats that a new trophy is based on are computed correctly, because usually stats that trophies are based on are included in the extendedMatchResult. The only exception are trophies based on features.

possible future extensions

• This doesn't help with feature based trophies yet.
• It is not possible to analyze the difficulty of a trophy with this.

[MarlonWelter]

There is a new issue that emerged from this: #71