E2e refactor

[jwgmeligmeyling]

• Managed to shrink the e2e tests with 50 lines. Imo a bit more readable this way.
• Added an injection test rule that allows to inject Moodcat objects (DAO's, backends) into e2e tests.

[TimvdLippe]

Personally I don't agree that the Builder pattern is more readable than the initial approach. However, I do agree that the current GET and POST magic in EndToEndTest class can be improved. I just don't think this solution makes it more elegant, it simply delegates the 'problem' to every subclass imo.

The SoundCloud mocking seems a good idea though, so maybe make a seperate PR for that?

My 2 cents.

[jwgmeligmeyling]

I like builders over parameters because they are more expressive. When you're e2e testing an API, you want to make sure you immediately see:

• Method (POST, PUT, GET)
• Endpoint (url)
• Request body / type
• Headers
• Response body / type

When creating lots of delegating methods that roughly do the same, you lose a bit of required logic of the HttpClient, but you sacrifice a few other points:

• You do not know what the parameters represent, you have to look into the method declaration to see what you are doing
• You do not sure what the actual invocation is, because the abstract is allowed to append data to the request
• As the testcases implement the abstract EndToEnd test, they have the (inherited) knowledge about HttpClient anyway.
• There is more duplicate code because of the very similar constructs (we saved approx. 50 lines this way)

[TimvdLippe]

Closing since we are discontinueing this project.