Issue #181: Write integration tests for PaymentController #205
Conversation
…s entity relationships
Codecov Report
@@ 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.
|
There was a problem hiding this comment.
@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
integration-tests/src/test/java/com/myhome/controllers/PaymentControllerIntegrationTest.java
Show resolved
Hide resolved
|
|
||
| @BeforeEach | ||
| public void setUp() { | ||
| ResponseEntity<Void> loginResponse = TestUtils.Login.performLogin(testRestTemplate, env); |
There was a problem hiding this comment.
We do not need to call login endpoint. We can create JWT token manually as non expiring one.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Okay I can agree to that 👍
| private TestRestTemplate testRestTemplate; | ||
|
|
||
| @Autowired | ||
| private Environment env; |
There was a problem hiding this comment.
Let's do not use a environment for url scrapping.
Would be better to have it as string duplicated in integration tests
|
@rmgrimm |
🚀 Description
This adds success-path integration tests for PaymentController; however, the test for scheduling payments needed to be marked as
@Disableddue 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
✅ Checklist