poorbarcode commented on code in PR #16758:
URL: https://github.com/apache/pulsar/pull/16758#discussion_r937021228
##########
pulsar-transaction/coordinator/src/test/java/org/apache/pulsar/transaction/coordinator/impl/TxnLogBufferedWriterTest.java:
##########
@@ -60,8 +61,14 @@
import org.testng.annotations.Test;
@Slf4j
+@Test(groups = "broker")
Review Comment:
> If you have a scenario for batchRecordCount > max records flush, then
check metric there, no?
U are right. Now we have three ways of writing test code:
- Understand all the internal logic of one method and write tests based on
the logic of the code.
- We are only concerned with inputs and outputs. For example, input 1+1,
return 2. We don't care what the internal logic is, we only care about whether
the outcome is correct.
- Combining the first two approaches: we simulate multiple inputs based on
known logic and then verify that the output is correct.
I think the third way is the best, there have two ways to do it.
e.g. the logic has two conditions: [a, b].
- way-1: we should write 4 unit test method
- a = true, b = true
- a = false, b = false
- a = true, b = false
- a = false, b = true
- way-2: we should write only 1 unit test method
- write a test that handles all scenarios
- create a data provider: [{true,true}, {false, false}, {true, false},
{false, true}]
If the logic has too many conditions, then the second implementation will
have the advantage of being easier to read and maintain.
I will write a separate PR to tidy up the test method `testMainProcess` and
make it easier to understand, Thanks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
