Why should general Java developers care about JSR-310 and the TCK?
Most developers have used the current date APIs that are available in Java. They're difficult to use, often lead to unexpected results and have a general confusion about them. JSR-310 aims to address these problems and ensure a better system for the future of Java. If contributions are not made by the community and Java developers this important JSR will miss the deadline for Java 8. My aim is to help get this through to Java 8 and I'm looking for as many people in the community to enable us to get there. Please feel free to contact me for more information:
- Twitter @goughjam
Before you can appreciate the reason for a TCK the first step is understanding the separation of concerns between the JSR (Java Specification Request) and the RI (Reference Implementation). The JSR has the purpose of stipulating the exact requirements of an implementation and is effectively the basis for the JavaDoc style interfaces, rather than getting bogged down in the implementation details. The reference implementation's job is to be the code that fulfills the requirements, it should do no more and no less than what is required from the specification. The job of the TCK is to mediate the specification against the actual implementations, keeping in mind that there might be more that one implementation for a specific JSR.
What's the difference between unit testing and TCK testing? What do both address? Is there any overlap?
The purpose of a TCK is to test the "conformance" of an implementation against a JSR, but it's more than just that. It is a suite of tools, a test framework and documentation to allow someone to take the JSR and understand how the implementation must behave to pass the kit. Unit tests are internal to the reference implementation and are not necessarily going to provide the full suite and documented nature of a TCK. Is there opportunity for reuse, definitely! However the unit tests that might be reused from an existing implementation need to be selected with care. The tests should only be testing the specification rather than any specific functionality that could be internal to an implementation. In the example of ThreeTen the strategy will be to view the JSR Early Draft Review independently from the code base that already exists to ensure a high quality TCK is created.
What makes up a TCK?
As mentioned the TCK is suite of tools to allow an implementer to create a successful reference implementation. It also requires careful planning, this is the phase we are landing in now for JSR-310. We will be looking over the coming weeks to produce the following plans; project, test, integration, documentation and QA plans. The previous sentence is quite work heavy to look at on first glance and immediately it's clear to see that the TCK is a project and application in itself.
The TCK needs to have the concept of conformance rules. These rules will measure the success of whether the implementation conforms to the specification. The test suite is a collection of conformance tests. The TCK should also allow the identification of methods that might be outside of the JSR, additional methods should cause the test to fail with a detailed description of the failure.
Because this is a piece of software what will be used by other developers, the error messages that are generated from the TCK need to be logical and clear as to why that test failed. Reporting and good user feedback is part of this framework.
Following the completion of a JSR the TCK doesn't end, it should enter a maintenance phase. It is possible that over time errors will be spotted in the TCK and this needs to managed over time.
What resources are required to build a TCK?
People! People from the community and experts from the Java ecosystem. However, before this can be done we need to ensure that the planning phase is well underway before the actual development can take place. For people interested in ThreeTen and JSR-310 please familiarise yourself with the following documents and websites:
- The JSR Specification
- ThreeTen Documentation
- ThreeTen on GitHub
- How to build a TCK
- Lightning talk introduction
- About a new date time API blogpost
It depends on the number of test cases that are identified, this will be part of the planning phase. A potential formula directly from the How to build a TCK document:
Where:(A-Num × CovBreadth ÷ DevRate) × NumEng = Test Development Time (in weeks)
- A-Num is the number of testable assertions defined by the specification.
- CovBreadth is the coverage breadth goal. For example, 0.75 for 75% breadth coverage.
- (Note that the ideal practice is to thoroughly test all elements which requires 100% breadth and depth coverage. Assertion breadth coverage of only 75% means that assertion testing is incomplete.)
- DevRate is the test development rate. According to Sun's experience a typical test development rate is approximately 12.5 test cases per week for a test developer to write, document, and debug assertion test cases (including simple test framework development).
- NumEng is the number of engineers writing tests.
How can you get involved?
We are looking for volunteers to help us build the TCK implementation and that effort will be increasing over the next few weeks. If you are interested or would like to know any more information please drop me an E-Mail. There are many levels at which you can be involved with a project like this, it might be that you'd like to write some technical documentation, or actually get stuck into the code. Whatever challenge you are looking for, we look forward to having you on board.
