Add documentation for developers on how to test #131
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| --- | ||
| layout: default_md | ||
| title: Testing changes locally | ||
| title-class: page-title-classic | ||
| type: classic | ||
| --- | ||
|
|
||
| [Developers](developers) > [Testing changes locally](testing-changes-locally) | ||
|
|
||
| Testing changes locally | ||
| ----------------------------- | ||
|
|
||
| ### Broker | ||
| After running existing or newly added unit tests, if you want to do integration testing on your change, you can [build](building) the repo locally to generate the release bundle and then unzip the bundle to test broker behaviour. | ||
| ``` | ||
| # At root directory | ||
| $ mvn -Dtest=false -DfailIfNoTests=false clean install | ||
|
Member
There was a problem hiding this comment.
|
||
| ``` | ||
| If the build was successful. You will see a message similar to the one below | ||
| ``` | ||
| [INFO] Installing /Users/xxx/amzn/personal_workspace/activemq/assembly/target/apache-activemq-6.2.0-SNAPSHOT-bin.zip to /Users/xxx/.m2/repository/org/apache/activemq/apache-activemq/6.2.0-SNAPSHOT/apache-activemq-6.2.0-SNAPSHOT-bin.zip | ||
|
Comment on lines
+19
to
+21
Member
There was a problem hiding this comment. I think either this can use far more generalised paths, e.g <home-dir> prefix, or /path/to/.....or better yet, it would maybe not be here at all. The typical place to point to Maven build output is a module |
||
| ``` | ||
| Unzip that target and start the ActiveMQ broker which contains your change | ||
| ``` | ||
| $ cd /Users/xxx/.m2/repository/org/apache/activemq/apache-activemq/6.2.0-SNAPSHOT | ||
| $ unzip apache-activemq-6.2.0-SNAPSHOT-bin.zip | ||
| $ cd apache-activemq-6.2.0-SNAPSHOT | ||
| $ ./bin/activemq console | ||
|
Member
There was a problem hiding this comment. People shouldnt be directed to extract stuff into their maven local repo and pollute it with non-build content thats likely to go stale. They can extract it in the build directories (i.e target) that will be cleaned up any time they do a clean. |
||
| ``` | ||
|
|
||
| ### ActiveMQ client | ||
|
|
||
| Testing the client library is a bit trickier because you will need a test client (that imports your newly built client library). There are many ways to do it, overall the idea is: | ||
|
|
||
| - Build the activemq-client pakcage | ||
| - Copy the output jar into your test client or local mvn repository | ||
| - Run your test client | ||
|
|
||
| You can take a look at this [sample test client](https://github.com/kenliao94/activemq-client-test) and follow its README. | ||
|
Member
There was a problem hiding this comment. Typo in pakcage. Directing folks to something in the existing examples (e.g. also included in the distribution built and used above) would seem far nicer than adding yet another, especially one complicated with shading, and which we also wouldn't want to link to an non-project repo for. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd expect a page about 'testing changes locally' to actually actually cover something about the tests, or at the very least reference to some other existing content that does speak to running tests, rather than gloss over it with simply "After running existing or newly added unit tests".
Maybe the page title needs a rethink. This seems more about 'running an example with your locally-built changes'.