Challenge Overview
pxCore is a client library that houses a large number of drawing objects and C++ functionality. You can find it in Github here: https://github.com/topcoderinc/pxCore/tree/_rtRemote_Java
rtRemote is a separate peer-to-peer RPC wrapper library around rtObject. It has no broker, but includes a location service for object discovery. Applications can communicate using TCP and UNIX Domain sockets, but other transports can be installed or “plugged in”. The API allows read/write on properties and method invocation. The type system supports most of what rtValue supports. rtValue is a VARIANT type. rtRemote currently is being developed, and we have been asked by the client to implement an rtRemote counterpart in pure Java and Node. This challenge will implement Java unit tests for the Java functionality we've recently implemented.
This challenge will focus on the Java code in the "remote/java" folder of our pxCore fork (https://github.com/topcoderinc/pxCore/tree/_rtRemote_Java).
Coverage
As a rule of thumb, we'd like to provide 80% coverage of the code with unit tests. Note that it's more important that the critical paths are covered, but shooting for 80% coverage is a good goal.
Framework
In addition to the unit tests, you should provide clear documentation on how to:
Failing tests
The Java implementation likely has bugs in it, or missing functionality. Don't expect that all your tests should pass - it's better that we have well-written tests that fail so we can fix bugs and then validate the results. You are encouraged to provide a document describing any failing tests so that reviewers are aware of the existing code deficiencies.
One item that was recently reported (in the C++ implementation, which may or may not affect the Java version):
- In the C++ server, when writing to the "ddouble" property, which has a DOUBLE type, it seems the property has the float precision, even though it seems it has declared the right type. Well, more or less, it is strange. It is like it doesn't support numbers with several integer digits. I've had failures with a number of integer digits of about 5 (i.e. 19912.312391). If I test with the same number, but with just 4 digits (i.e. 1991.2312391), then it works correctly.
Documentation
You are expected to bring the documentation up to our standard, including deployment guide, README, and validation guide.
Target Environment:
We've had good luck with Ubuntu 16.04, and there are instructions for building pxScene in the repository. Once you've built pxScene, you can easily build the rtRemote examples for testing. Note that if you get Duktape errors on building, you can disable Duktape in pxScene using this cmake command: cmake .. -DSUPPORT_DUKTAPE=OFF
Submission requirements
Your submission should include:
* Updated test code that meets there requirements above. A patch file against commit hash 91bd92ee5b032c120da42b4c8216e0d7f7ba9bb4 or later in the _rtRemote_Java branch is required
* README describing the code, setup, and deployment / compilation details
* Validation document describing the tests and how they can run and how coverage documentation can be generated
A video is not required for this challenge
rtRemote is a separate peer-to-peer RPC wrapper library around rtObject. It has no broker, but includes a location service for object discovery. Applications can communicate using TCP and UNIX Domain sockets, but other transports can be installed or “plugged in”. The API allows read/write on properties and method invocation. The type system supports most of what rtValue supports. rtValue is a VARIANT type. rtRemote currently is being developed, and we have been asked by the client to implement an rtRemote counterpart in pure Java and Node. This challenge will implement Java unit tests for the Java functionality we've recently implemented.
Requirements
This challenge will focus on the Java code in the "remote/java" folder of our pxCore fork (https://github.com/topcoderinc/pxCore/tree/_rtRemote_Java).
Coverage
As a rule of thumb, we'd like to provide 80% coverage of the code with unit tests. Note that it's more important that the critical paths are covered, but shooting for 80% coverage is a good goal.
Framework
We can target JUnit 5 for the unit tests (https://junit.org/junit5/). If you think a different framework may make more sense for this project, you are free to propose it in the forum for approval.
DocumentationIn addition to the unit tests, you should provide clear documentation on how to:
- Run the tests
- Generate a coverage report
Failing tests
The Java implementation likely has bugs in it, or missing functionality. Don't expect that all your tests should pass - it's better that we have well-written tests that fail so we can fix bugs and then validate the results. You are encouraged to provide a document describing any failing tests so that reviewers are aware of the existing code deficiencies.
One item that was recently reported (in the C++ implementation, which may or may not affect the Java version):
- In the C++ server, when writing to the "ddouble" property, which has a DOUBLE type, it seems the property has the float precision, even though it seems it has declared the right type. Well, more or less, it is strange. It is like it doesn't support numbers with several integer digits. I've had failures with a number of integer digits of about 5 (i.e. 19912.312391). If I test with the same number, but with just 4 digits (i.e. 1991.2312391), then it works correctly.
Documentation
You are expected to bring the documentation up to our standard, including deployment guide, README, and validation guide.
Target Environment:
We've had good luck with Ubuntu 16.04, and there are instructions for building pxScene in the repository. Once you've built pxScene, you can easily build the rtRemote examples for testing. Note that if you get Duktape errors on building, you can disable Duktape in pxScene using this cmake command: cmake .. -DSUPPORT_DUKTAPE=OFF
Submission requirements
Your submission should include:
* Updated test code that meets there requirements above. A patch file against commit hash 91bd92ee5b032c120da42b4c8216e0d7f7ba9bb4 or later in the _rtRemote_Java branch is required
* README describing the code, setup, and deployment / compilation details
* Validation document describing the tests and how they can run and how coverage documentation can be generated
A video is not required for this challenge