2017-09-05 16:21:07 +00:00
|
|
|
Testing Corda
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
Automated Tests
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
Corda has a maintained suite of tests that any contributing developers must maintain and add to if new code has been added.
|
|
|
|
|
|
|
|
|
|
There are several distinct test suites each with a different purpose;
|
|
|
|
|
|
|
|
|
|
**Unit tests**: These are traditional unit tests that should only test a single code unit, typically a method or class.
|
|
|
|
|
|
|
|
|
|
**Integration tests**: These tests should test the integration of small numbers of units, preferably with mocked out services.
|
|
|
|
|
|
|
|
|
|
**Smoke tests**: These are full end to end tests which start a full set of Corda nodes and verify broader behaviour.
|
|
|
|
|
|
|
|
|
|
**Other**: These include tests such as performance tests, stress tests, etc, and may be in an external repo.
|
|
|
|
|
|
2017-09-05 16:38:53 +00:00
|
|
|
These tests are mostly written with JUnit and can be run via ``gradle``. On windows run ``gradlew test integrationTest
|
|
|
|
|
smokeTest`` and on unix run ``./gradlw test integrationTest smokeTest`` or any combination of these three arguments.
|
2017-09-05 16:21:07 +00:00
|
|
|
|
|
|
|
|
Before creating a pull request please make sure these pass.
|
|
|
|
|
|
|
|
|
|
Manual Testing
|
|
|
|
|
--------------
|
|
|
|
|
|
|
|
|
|
Manual testing would ideally be done for every set of changes merged into master, but practically you should manually test
|
|
|
|
|
anything that would be impacted by your changes. The areas that usually need to be manually tested and when are below;
|
|
|
|
|
|
|
|
|
|
**Node startup** - changes in the ``node`` or ``node:capsule`` project in both the Kotlin or gradle or the ``cordformation`` gradle plugin.
|
|
|
|
|
|
|
|
|
|
**Sample project** - changes in the ``samples`` project. eg; changing the IRS demo means you should manually test the IRS demo.
|
|
|
|
|
|
|
|
|
|
**Explorer** - changes to the ``tools/explorer`` project.
|
|
|
|
|
|
|
|
|
|
**Demobench** - changes to the ``tools/demobench`` project.
|
|
|
|
|
|
|
|
|
|
How to manually test each of these areas differs and is currently not fully specified. For now the best thing to do is
|
|
|
|
|
ensure the program starts, that you can interact with it, and that no exceptions are generated in normal operation.
|
|
|
|
|
|
2017-10-20 14:14:14 +00:00
|
|
|
TODO: Add instructions on manual testing
|
|
|
|
|
|
|
|
|
|
External Database Testing
|
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
By default, all tests which need a database, utilize built-in H2 instances. In case the testing with other database backends
|
|
|
|
|
or other database setup (H2 in server mode for example), while running tests extra parameters can be used to specify required
|
|
|
|
|
properties. Appropriate changes will then be applied to all tests in a appropriate manner.
|
|
|
|
|
|
|
|
|
|
- ``dataSourceProperties.dataSource.url`` - JDBC datasource URL. Appropriate drivers must be available in classpath. Also, for
|
|
|
|
|
different tests random database name is appended at the end of this string, ie. ``jdbc:h2:tcp://localhost:9092`` will become
|
|
|
|
|
full, proper URL - ie.``jdbc:h2:tcp://localhost:9092/34jh543gk243g2`` - mind the last slash missing.
|
|
|
|
|
|
|
|
|
|
- ``dataSourceProperties.dataSourceClassName`` - JDBC driver classname - defaults to ``org.h2.jdbcx.JdbcDataSource``)
|
|
|
|
|
|
|
|
|
|
- ``dataSourceProperties.dataSource.user`` - JDBC username - defaults to ``sa``
|
|
|
|
|
|
|
|
|
|
- ``dataSourceProperties.dataSource.password`` - JDBC password - defaults to ``""`` (Empty string)
|
