ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-03-15 00:36:49 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'merge-point-c419605' into shams-os-merge-231118

Browse Source 
# Conflicts:
#	CONTRIBUTING.md
#	build.gradle
#	docs/source/api-scanner.rst
#	docs/source/building-corda.rst
#	docs/source/contributing-index.rst
#	docs/source/contributing.rst
#	docs/source/testing.rst
#	node/capsule/build.gradle
#	node/src/main/kotlin/net/corda/node/services/schema/NodeSchemaService.kt
#	node/src/main/resources/migration/vault-schema.changelog-master.xml
This commit is contained in:
Shams Asari 2018-11-23 16:34:49 +00:00
commit 6f79e60a9d
3 changed files with 25 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
docs/source/testing.rst
View File

@ -1,42 +1,38 @@
Testing Corda
=============
Testing your changes
====================
Automated Tests
Automated tests
---------------
Corda has a suite of tests that any contributing developers must maintain and extend when adding new code.
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 test suites:
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.
**Unit tests**: These are traditional unit tests that should only test a single code unit, typically a method or class.
Running the automated tests
^^^^^^^^^^^^^^^^^^^^^^^^^^^
These tests are mostly written with JUnit and can be run via ``gradle``:
**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.
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.
* **Windows**: Run ``gradlew test integrationTest smokeTest``
* **Unix/Mac OSX**: Run ``./gradlew test integrationTest smokeTest``
Before creating a pull request please make sure these pass.
Manual Testing
Manual testing
--------------
You should manually test anything that would be impacted by your changes. The areas that usually need to be manually tested and when are
as follows:
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.
**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.
How to manually test each of these areas differs and is currently not fully specified. For now the best thing to do is to ensure the
program starts, that you can interact with it, and that no exceptions are generated in normal operation.
TODO: Add instructions on manual testing

3
node/src/main/kotlin/net/corda/node/services/schema/NodeSchemaService.kt
View File

@ -45,7 +45,8 @@ class NodeSchemaService(private val extraSchemas: Set<MappedSchema> = emptySet()
PersistentIdentityService.PersistentIdentityNames::class.java,
ContractUpgradeServiceImpl.DBContractUpgrade::class.java,
RunOnceService.MutualExclusion::class.java,
PersistentKeyManagementService.PublicKeyHashToExternalId::class.java)) {
PersistentKeyManagementService.PublicKeyHashToExternalId::class.java
)) {
override val migrationResource = "node-core.changelog-master"
}

1
node/src/main/resources/migration/vault-schema.changelog-master.xml
View File

@ -12,5 +12,4 @@
<include file="migration/vault-schema.changelog-pkey-swap.xml"/>
<include file="migration/vault-schema.changelog-v7.xml"/>
<include file="migration/vault-schema.changelog-v8.xml"/>
</databaseChangeLog>