Issue #181: Write integration tests for PaymentController

[rmgrimm]

🚀 Description

This adds success-path integration tests for PaymentController; however, the test for scheduling payments needed to be marked as @Disabled due to the API throwing a NullPointerException any time enough data is included to avoid the 404.

📄 Motivation and Context

This handles one of the bullet points of #181 .

🧪 How Has This Been Tested?

Running ./gradlew clean test will go through all the integration tests.

📦 Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

✅ Checklist

• My code follows the code style of this project(Do your best to follow code styles. If none apply just skip this).
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[codecov]

Codecov Report

Merging #205 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #205   +/-   ##
=========================================
  Coverage     67.74%   67.74%           
  Complexity      174      174           
=========================================
  Files            27       27           
  Lines           744      744           
  Branches         31       31           
=========================================
  Hits            504      504           
  Misses          232      232           
  Partials          8        8           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a24da1c...fe13624. Read the comment docs.

[mslowiak]

@rmgrimm
There are some changes needed take a look there.

@rmgrimm @jmprathab
I need to create separate stories regarding each integration test to point to it directly via PR

[mslowiak]

We do not need to call login endpoint. We can create JWT token manually as non expiring one.

[rmgrimm]

I understand. But by calling the login endpoint, we can guarantee that a regular flow will be workable for users interacting with the system outside of the controlled test environment. If we generate a JWT token directly, we either:

• potentially bypass any info that gets encoded into it by the real login and therefore deviate from testing functionality that a real user might see, or
• duplicate a good portion of the login logic and make sure all future changes need to be kept up-to-date, or
• maybe even both

If this was a unit test, I'd completely agree with you that it shouldn't be relying on external behavior. As this is instead an integration test, I went with simulating real calls for the full test.

[mslowiak]

Okay I can agree to that 👍

[mslowiak]

Let's do not use a environment for url scrapping.
Would be better to have it as string duplicated in integration tests

[mslowiak]

@rmgrimm
Let me create the issues for the integration tests so we can merge it in a proper way.
Need like 1-2 days.