You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pruned a bunch of legacy features so had to fix/comment out a bunch of similarly outdated code in my /tests section. (Come back and rehaul my integration tests later this week).
Copy file name to clipboardExpand all lines: springqpro-backend/src/test/java/com/springqprobackend/springqpro/integration/TaskGraphQLIntegrationTest.java
queue = newQueueService(immediateExecutor, handlerRegistry, taskRepo, proService, props, queueEnqueueCounter, queueEnqueueByIdCounter); // Manually constructing the queue (which is why there's no annotation above it earlier).
95
+
//queue = new QueueService(immediateExecutor, handlerRegistry, taskRepo, proService, props, queueEnqueueCounter, queueEnqueueByIdCounter); // Manually constructing the queue (which is why there's no annotation above it earlier).
96
96
// Init Task w/ no-args constructor:
97
97
t = newTask();
98
98
// id and type fields are the ubiquitous fields for testing (e.g., for identification):
@@ -104,14 +104,14 @@ void setUp() {
104
104
@Test
105
105
voidenqueue_shouldAddTask_toJobsMap() {
106
106
// DEBUG:+NOTE: No type field causes error I'm pretty sure. Not sure about id though (maybe it should -- come back and look into this later).
107
-
queue.enqueue(t);
107
+
//queue.enqueue(t);
108
108
/* EDIT: So it checks for FAILED before for a reason. We don't really care about what the Worker/Executor actually does, I just want to
109
109
make sure that this Task gets enqueued into the pool and added to the jobs map (and so on). It will FAIL because I'm now relying on the
110
110
direct executor that I define in the nested class. So even if I have a when...thenReturn(); call somewhere, it won't work. But that's okay
111
111
because that's not really the concern of this Test. (I could just not use the direct executor if this were something I were actually concerned about). */
112
-
assertEquals(TaskStatus.FAILED, t.getStatus());
113
-
assertEquals(1, queue.getJobMapCount()); // Each test runs in isolation, so 1 job w/ only one task queued.
/* NOTE: Tasks of Type EMAIL take ~2 seconds to finish execution (after which, their Type becomes COMPLETED).
116
116
I could potentially make this thread sleep for 2-3 seconds and then check after to see if the type becomes COMPLETED.
117
117
But I think it's supposed to be bad practice doing that in Unit Tests since they're meant to be very quick...
@@ -121,12 +121,12 @@ make sure that this Task gets enqueued into the pool and added to the jobs map (
121
121
@Disabled
122
122
@Test
123
123
voidclear_shouldEmpty_theJobsMap() {
124
-
queue.enqueue(t); // enqueue this job just so that the clear method can be invoked.
124
+
//queue.enqueue(t); // enqueue this job just so that the clear method can be invoked.
125
125
126
126
// DEBUG: Not sure if this would work honestly. Get some clarity on if the execution of this test would be sequential (it should be right? Why am I questioning this?)
127
-
queue.clear();
128
-
assertEquals(0, queue.getJobMapCount());
129
-
assertNull(queue.getJobById("Task-ArbitraryTestId"), ()->"The value returned by getJobById() should be null post-clear()");
127
+
//queue.clear();
128
+
//assertEquals(0, queue.getJobMapCount());
129
+
//assertNull(queue.getJobById("Task-ArbitraryTestId"), ()->"The value returned by getJobById() should be null post-clear()");
assertNull(queue.getJobById("Task-ArbitraryTestId"), ()-> "The value returned by getJobById(\"id\") should be null after deleting the job identified by \"id\"");
151
+
//queue.deleteJob("Task-ArbitraryTestId");
152
+
//assertEquals(0, queue.getJobMapCount());
153
+
//assertNull(queue.getJobById("Task-ArbitraryTestId"), ()-> "The value returned by getJobById(\"id\") should be null after deleting the job identified by \"id\"");
154
154
}
155
155
156
156
@Disabled
@@ -170,7 +170,7 @@ immediately after that (the when... func never runs) -- and in the context of th
170
170
/* NOTE: retry method in QueueService.java is supposed to *not run* if the task you send in is NOT a FAILED status type.
171
171
I think that might have been removed from my code when I refactored away from the switch-case method of handling different tasks.
172
172
(I'm not 100% sure, come back to this and do some more digging - can probably be another unit test in this file). */
173
-
queue.retry(t, 10);
173
+
//queue.retry(t, 10);
174
174
TimeUnit.MILLISECONDS.sleep(20);
175
175
/* In the context of this text below, I think we can just it check if the TaskStatus is COMPLETED (we're defining the
176
176
handler behavior in the when...thenReturn(); method above anyways; I could have made it be QUEUED instead). */
@@ -179,19 +179,19 @@ immediately after that (the when... func never runs) -- and in the context of th
179
179
I enforce in this test delay it enough that the queued Worker reaches the stage where its Task Status is set to INPROGRESS.
180
180
So, I may as well just also have the when...thenReturn(); function set the same (since we just want to make sure that it
181
181
gets re-enqueued regardless of what the status is when we check). */
0 commit comments