So I have managed to create the silliest of test scripts e.g.
module TestRepo where
import FixedInstruments
repo_test_1 =
scenario do
jpm <- getParty "JPM"
fed <- getParty "FED"
submit jpm do
create Repo
with owner = jpm; regulator = fed ; par = 1.5; cusip = "9999999"
based on this:
module FixedInstruments where
template Repo
with
owner : Party
regulator : Party
par : Decimal
cusip : Text
where
signatory owner
observer regulator
which generated this:
Transactions:
TX 0 1970-01-01T00:00:00Z (TestRepo:9:13)
#0:0
│ known to (since): 'FED' (0), 'JPM' (0)
└─> create FixedInstruments:Repo
with
owner = 'JPM'; regulator = 'FED'; par = 1.5000000000; cusip = "9999999"
Active contracts: #0:0
Return value: #0:0
granted useful.
Yet I’m so used to setting up Spock specs, so again I’m trying to fast track myself to setting up a series of unit test I can auto run in a more common setup.
To do so, it requires that:
I can launch a ledger as part of the before all test setup of the test suite
that respective testing api exists via the Java SDK e.g. getParty, allocateParty , create and so forth
that thru the create cmd I have a means of retrieving an identifying hash for the transaction so that I can then look it up later , in order to setup asserts based on said transaction and therein contained contracts
So my question is do the above requisites exist ? i.e. is all of this part of the JAVA Ledger API ?
Does an example of testing daml via for example Junit exist ?
Finally, I invariably will develop “testing” UIs as I usually do which will include in this case some sort of ledger explorer although perhaps the Navigator will spare me the exercise
the issue there is can somebody pls point me to how I can maintain a local “persisted” daml ledger to assist in this secondary type of testing
You can run daml start to do this, you’ll find the daml assistant has many useful commands and you can see them all with daml --help and daml your_command_here --help.
You don’t need to, you would create them and reference them in Daml Script when consuming them.
There is a daml test command to run unit tests. You could write tests in Java as well but beyond the bindings we don’t have anything available to do this and you’ll likely find it easier to write in Daml Script both from an ease of maintenance (Script will easily show you when a change to your templates has broken a Script and how), and an ease of learning Daml.
thank you for your feedback , pls see my responses to your responses
Fine, so I will have to run an external process call so that’s ready before the test suite runs, there might be a timing issue to contend with. Unlike Corda for example ,there’s not even the notion of a Mock ledger that can be instantiated ?
I’m sorry, I’m confused by your response since what I stated I would like to do is to use the Java api not the daml script api, since I would plan to setup Groovy unit tests using either Junit or Spock. Scanning your reference it seems that this is all about daml script which is certainly a viable path but not what I want to do now
Never mind testing, So is it the case that via the Java SDK that the contract creation api does not return an id which can then be used subsequently for querying. I’ll study the Java API for that.
I appreciate what you all have built and I’m not dismissing it but for us using it as the primary mechanism of testing will not work, I certainly see for us its value in exploration
Our stack is Groovy for both dev/testing and we will build UIs with JavaFX.
Now that I reflect better on this issue , it would seem that anything I can do from a UI i.e. creation , querying I should be able to do from a unit test , and therefore I need to bite the bullet and learn that Java Ledger API .
There are two types of testing that you commonly use for Daml applications:
The equivalent of a unit test where you only test interaction of your model with the ledger or even individual functions that don’t do any ledger interaction. I highly recommend using Daml Script for this for a few reasons:
You get integration in Daml Studio. Scripts are run automatically and you can see the ledger state. This also leads to better iteration cycles. Modifying a file in a larger project and seeing the potentially different script result in Daml Studio is much faster than recompiling your project, uploading it to a ledger and rerunning your Java tests which makes debugging much more pleasant.
Even in CLI usage, daml test runs against a special ledger which provides more information on failed tests and is much faster than spinning up Sandbox against that.
The test code becomes much simpler, you can use the same types you’ve already defined in Daml, you don’t need a code generator, ….
You can test individual functions without wrapping them in choices.
Integration tests that check your Daml model but also triggers, Java code you’ve written, maybe a UI and everything else that is part of a full Daml application. You can use Daml Script to some degree for those and run it against a real ledger instead of via daml test but I think for those cases, Java is a very sensible choice. You might be interested in GitHub - digital-asset/lib-daml-jvm-test: A library providing functions for testing DAML applications on JVM. which provides some utilities for this (note that this is not part of Daml Connect though so you don’t get the same support).
Here are some examples for high level integration tests in Java, testing if a given workflow succeeds using a Sandbox ledger and some Triggers, illustrating the second point of @cocreature
, and therefore I need to bite the bullet and learn that Java Ledger API .