<p>TestNg is a bit (tiny bit) more powerful than junit, but is less known, so I would stick with junit to keep barrier for new Devs low.</p>
<p>I do not like parameterized tests. The name of the test should tell what scenario it tests.<br>
Unit tests must be dead simple, this short, of they're not, they will not be maintainable and will lose documentation valor.<br>
When parameterized test fails you don't know what the scenario was by looking at test report. You have to inspect the code, which is a pain when tests fail on ci.</p>
<p>As to mocking frameworks, I've used mockito a lot and it has everything needed.<br>
It does not support mocking of static methods, but if you need to mock such methods than your design is wrong IMHO.</p>
<p>We should also consider Arquillian as an integration testing framework. It comes with a lot of plugins, but the most useful for us is the Cube, which allows to spin up docker containers and run tests against them.<br>
I'm using this heavily in the API development and it allows me to run the whole trade flow on regtest with Alice, Bob and arbitrator bisque nodes in separate containers, as well as seednode and bitcoind node.<br>
I bet we could write tests that would work on testnet or even mainnet (that would of course cost is money in terms of transaction and trade fees).<br>
IMHO Arquillian is future for Bisq testing effort, once we get the API running.</p>
<p>Right now for me the biggest problem with unit testing Bisq is the amount of dependencies that need to be mocked. The <code>given</code> part takes 20-30 lines, which makes the whole test unreadable, this defeating it's purpose.</p>
<p>Summing up: I'm for junit4 and Arquillian.<br>
Unfortunately Arquillian does not support junit5.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/74#issuecomment-464423575">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AkpZtm3EL4SJOHeNaabspqCCRCAJDPuDks5vOP5DgaJpZM4a91Ar">mute the thread</a>.<img src="https://github.com/notifications/beacon/AkpZtoaAhCS3z1w_WRCJro9x5yCnntQ_ks5vOP5DgaJpZM4a91Ar.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bisq-network/proposals","title":"bisq-network/proposals","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/bisq-network/proposals"}},"updates":{"snippets":[{"icon":"PERSON","message":"@blabno in #74: TestNg is a bit (tiny bit) more powerful than junit, but is less known, so I would stick with junit to keep barrier for new Devs low.\r\n\r\nI do not like parameterized tests. The name of the test should tell what scenario it tests.\r\nUnit tests must be dead simple, this short, of they're not, they will not be maintainable and will lose documentation valor.\r\nWhen parameterized test fails you don't know what the scenario was by looking at test report. You have to inspect the code, which is a pain when tests fail on ci.\r\n\r\nAs to mocking frameworks, I've used mockito a lot and it has everything needed.\r\nIt does not support mocking of static methods, but if you need to mock such methods than your design is wrong IMHO.\r\n\r\nWe should also consider Arquillian as an integration testing framework. It comes with a lot of plugins, but the most useful for us is the Cube, which allows to spin up docker containers and run tests against them.\r\nI'm using this heavily in the API development and it allows me to run the whole trade flow on regtest with Alice, Bob and arbitrator bisque nodes in separate containers, as well as seednode and bitcoind node.\r\nI bet we could write tests that would work on testnet or even mainnet (that would of course cost is money in terms of transaction and trade fees).\r\nIMHO Arquillian is future for Bisq testing effort, once we get the API running.\r\n\r\nRight now for me the biggest problem with unit testing Bisq is the amount of dependencies that need to be mocked. The `given` part takes 20-30 lines, which makes the whole test unreadable, this defeating it's purpose.\r\n\r\nSumming up: I'm for junit4 and Arquillian. \r\nUnfortunately Arquillian does not support junit5."}],"action":{"name":"View Issue","url":"https://github.com/bisq-network/proposals/issues/74#issuecomment-464423575"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/74#issuecomment-464423575",
"url": "https://github.com/bisq-network/proposals/issues/74#issuecomment-464423575",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>