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 expand the existing C++ unit tests available to provide proper code coverage and documentation.
This challenge will focus on the C++ code in the "remote" folder of our pxCore fork (https://github.com/topcoderinc/pxCore/tree/_rtRemote_Java). There are existing tests in the "tests" folder, but we need to expand them quite a bit to provide proper coverage.
Classes in scope
Note that for the repost, we will limit the scope a bit. Only these files (and their corresponding headers) will be in scope:
* rtRemote.cpp
* rtRemoteClient.cpp
* rtRemoteConfig.cpp
* rtRemoteConfigGen.cpp
* rtRemoteEnvironment.cpp
* rtRemoteException.cpp
* rtRemoteFactory.cpp
* rtRemoteMapperFile.cpp
* rtRemoteMapperMap.cpp
* rtRemoteMapperSql.cpp
* rtRemoteMulticastResolver.cpp
* rtRemoteNameService.cpp
* rtRemoteNsResolver.cpp
* rtRemoteUtils.cpp
* rtRemoteValueReader.cpp
* rtRemoteValueWriter.cpp
* rtSampleClient.cpp
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 C++ implementation likely has bugs in it. 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++ 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 expand the existing C++ unit tests available to provide proper code coverage and documentation.
Requirements
This challenge will focus on the C++ code in the "remote" folder of our pxCore fork (https://github.com/topcoderinc/pxCore/tree/_rtRemote_Java). There are existing tests in the "tests" folder, but we need to expand them quite a bit to provide proper coverage.
Classes in scope
Note that for the repost, we will limit the scope a bit. Only these files (and their corresponding headers) will be in scope:
* rtRemote.cpp
* rtRemoteClient.cpp
* rtRemoteConfig.cpp
* rtRemoteConfigGen.cpp
* rtRemoteEnvironment.cpp
* rtRemoteException.cpp
* rtRemoteFactory.cpp
* rtRemoteMapperFile.cpp
* rtRemoteMapperMap.cpp
* rtRemoteMapperSql.cpp
* rtRemoteMulticastResolver.cpp
* rtRemoteNameService.cpp
* rtRemoteNsResolver.cpp
* rtRemoteUtils.cpp
* rtRemoteValueReader.cpp
* rtRemoteValueWriter.cpp
* rtSampleClient.cpp
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
The existing tests use Google Test (https://github.com/google/googletest). We should continue to use Google Test for our unit tests in this challenge. Here's documentation to get you up to speed:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.md
In addition to the unit tests, you should provide clear documentation on how to:
- Run the tests
- Generate a coverage report
Failing tests
The C++ implementation likely has bugs in it. 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++ 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