7c64992c73
Original change by cpovirk@cpovirk:rosie251284456-0055_Rosie:31511:citc on 2019/06/04 09:48:27.
Update to Truth 0.45, and address deprecations.
Renames may include:
- containsAllOf => containsAtLeast
- containsAllIn => containsAtLeastElementsIn
- isSameAs => isSameInstanceAs
- isOrdered => isInOrder
- isStrictlyOrdered => isInStrictOrder
The other major change is to change custom subjects to extend raw Subject instead of supplying type parameters. The type parameters are being removed from Subject. This CL will temporarily produce rawtypes warnings, which will go away when I remove the type parameters (as soon as this batch of CLs is submitted).
Some CLs in this batch also migrate calls away from actualAsString(). Its literal replacement is `"<" + actual + ">"` (unless an object overrides actualCustomStringRepresentation()), but usually I've made a larger change, such as switching from an old-style "Not true that..." failure message to one generated with the Fact API. In that case, the new code usually contains a direct reference to this.actual (a field that I occasionally had to create). Another larger change I sometimes made is to switch from a manual check-and-fail approach to instead use check(...). And sometimes I just remove a withMessage() call that's no longer necessary now that the code uses check(...), or I introduce a check(...) call. (An assertion made with check(...) automatically includes the actual value from the original subject, so there's no need to set it again with withMessage().)
Finally, there's one CL in this batch in which I migrate a Correspondence subclass to instead use Correspondence.from.
END_PUBLIC
If this is too many changes at once, let me know, and I can split it up and/or explain further. In the past, I've erred on the side of sending separate CLs for each change, which has required some owners to manually reapply each one, so now I'm trying this way.
Thanks again for your patience. There is an outside chance that this will be the last CL I send you before Truth 1.0 -- but certainly no promises :)
More information:
Renames:
[]
[]
[]
Removing type parameters: []
Migration from old fail*(...) methods to new ones and to check(...): []
Changes that replace assert*(...) with introduce check(...): []
Correspondence subclass to Correspondence.from: []
Tested:
TAP --sample ran all affected tests and none failed
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=251921007
|
||
|---|---|---|
| .. | ||
| buildSrc | ||
| config/checkstyle | ||
| core | ||
| gradle | ||
| node_modules | ||
| proxy | ||
| services | ||
| third_party | ||
| util | ||
| appengine_war.gradle | ||
| build.gradle | ||
| dependencies.gradle | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| java_common.gradle | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| settings.gradle | ||
This folder contains experimental Gradle scripts as an alternative to Bazel for the open-source Nomulus project. These are work-in-progress and are expected to evolve in the near future.
Gradle is configured to use the directory containing this file as root, but use the existing Nomulus source tree.
All testing is done with Gradle v5.1.1.
Notable Issues
Test suites (RdeTestSuite and TmchTestSuite) are ignored to avoid duplicate execution of tests. Neither suite performs any shared test setup routine, so it is easier to exclude the suite classes than individual test classes. This is the reason why all test tasks in the :core project contain the exclude pattern '"/TestCase.", "/TestSuite."'
Many Nomulus tests are not hermetic: they modify global state (e.g., the shared local instance of Datastore) but do not clean up on completion. This becomes a problem with Gradle. In the beginning we forced Gradle to run every test class in a new process, and incurred heavy overheads. Since then, we have fixed some tests, and manged to divide all tests into three suites that do not have intra-suite conflicts. We will revisit the remaining tests soon.
Note that it is unclear if all conflicting tests have been identified. More may be exposed if test execution order changes, e.g., when new tests are added or execution parallelism level changes.
Initial Setup
Install Gradle on your local host, then run the following commands from this directory:
# One-time command to add gradle wrapper:
gradle wrapper
# Start the build:
./gradlew build
From now on, use './gradlew build' or './gradlew test' to build and test your changes.
To upgrade to a new Gradle version for this project, use:
gradle wrapper --gradle-version version-number
Deploy to AppEngine
Use the Gradle task 'appengineDeploy' to build and deploy to AppEngine. For now you must update the appengine.deploy.project in build.gradle to your GCP project ID.
To deploy the Gradle build, you will need the Google Cloud SDK and its app-engine-java component.