claudenw / junit-contracts Goto Github PK

I recommend adding a simpler example, such as showing that ArrayList and LinkedList both respect the List contract. I also recommend publishing a tutorial in which you show adding a few more contract tests. I further recommend showing how to distinguish a test for ArrayList that wouldn't apply to LinkedList (such as for trimToCapacity()).

I'm on commit 8b8a264. mvn package fails:

Failed tests:   org.xenei.junit.contract.CImpl2ContractTest: expected:<[CImpl2ContractTest.producer.newInstance(), called Extra Method, CImpl2ContractTest.producer.cleanUp()]> but was:<[CImpl2ContractTest.producer.newInstance(), called Extra Method, CImpl2ContractTest.producer.cleanUp(), CImpl2ContractTest.producer.newInstance(), cname, CImpl2ContractTest.producer.cleanUp(), CImpl2ContractTest.producer.newInstance(), cname version of aname, CImpl2ContractTest.producer.cleanUp(), CImpl2ContractTest.producer.newInstance(), cname version of bname, CImpl2ContractTest.producer.cleanUp()]>

Tests in error:
  initializationError(org.xenei.junit.contract.AImplContractTest): No tests for class org.xenei.junit.contract.AImplContractTest
  initializationError(org.xenei.junit.contract.BImplContractTest): No tests for class org.xenei.junit.contract.BImplContractTest
  initializationError(org.xenei.junit.contract.CImplContractTest): No tests for class org.xenei.junit.contract.CImplContractTest
  initializationError(org.xenei.junit.contract.DImplContractTest): No tests for class org.xenei.junit.contract.DImplContractTest

I can't figure out what to do next. I don't understand the example well enough to see how the pieces fit together.

Your project, Claudenw/junit-contracts, depends on the outdated library FastClasspathScanner in the following source files:

• junit/src/main/java/org/xenei/junit/contract/info/ContractTestMap.java

FastClasspathScanner has been significantly reworked since the version your code depends upon:

• a significant number of bugs have been fixed
• some nontrivial API changes have been made to simplify and unify the API
• FastClasspathScanner has been renamed to ClassGraph: https://github.com/classgraph/classgraph

ClassGraph is a significantly more robust library than FastClasspathScanner, and is more future-proof. All future development work will be focused on ClassGraph, and FastClasspathScanner will see no future development.

Please consider porting your code over to the new ClassGraph API, particularly if your project is in production or has downstream dependencies:

• https://github.com/classgraph/classgraph/wiki/Porting-FastClasspathScanner-code-to-ClassGraph
• https://github.com/classgraph/classgraph/wiki/Code-examples
• https://github.com/classgraph/classgraph/wiki/ClassGraph-API

Feel free to close this bug report if this code is no longer in use. (You were sent this bug report because your project depends upon FastClasspathScanner, and has been starred by 13 users. Apologies if this bug report is not helpful.)

On non-case specific file systems location of classes will fail if the parameter is not in the same case as the file system (e.g. uppercase for windows)

parsing either "*" or "?" alone will result in a NoSuchElementException.

Currently the maven plugin will fail if no classes were located in the list of specific packages. There needs to be a flag to determine if the report should fail the build or simply report the error. Currently this impacts Windows systems as the package names in the parameters list may be mixed case (for unix) and then fail on windows.

I love the idea for junit-contracts. I fear that a TDD practitioner will look at the example test for the Serializable contract and have one of two unfortunate reactions: (1) "This test is absurd! This dude has no idea what he's talking about!" or (2) "Wow... that's a complicated test. I guess I should write more complicated tests." Both cause problems.

I strongly recommend splitting testSerializableContract() into several tests to illustrate a more sensible design for contract tests. For example, I see the following tests:

implementsWriteObjectMethod()
implementsReadObjectMethod()
implementsReadObjectNoDataMethodIfNeeded()
allFieldsThatNeedSerializingAreSerializable()
allFieldsThatAreNotSerializableDoNotNeedSerializing()

It's possible to break them down further.

Currently the ContractSuite fails with a "No tests found" error. It should log the error (not generate a testing failure) and let the maven plugin handle aborting the build.

The "skip" attribute of the ContractImpl annotation lists interfaces of the class under test that should not be tested.

The "ignore" attribute fo the @ContractImpl annotation lists the test implementations that apply t othe class under test that should not be executed.

However, there is no mechanism to exclude specific tests from test implementations. This is required when classes do not implement all the functionality the test exercises but other tests are applicable.

would it be possible to remove the logging at [INFO] for the next version of the contract framework?

ContractSuite.java:343
ContractTestMap.java:268

Messages like:
INFO main - Running: org.xenei.junit.contract.ContractSuite$BaseClassRunner@248e319b
INFO main - Running: org.xenei.junit.contract.ContractTestRunner@5d0bf09b
INFO main - Running: org.xenei.junit.contract.ContractTestRunner@793f29ff

aren't about the jena-core test suite.

    Andy

There may be issues when a class is initialized earlier than it should be. The class loader should load the class and explicitly not initialize the classes as we are only looking for annotations.

Once testing starts initializing the classes under test is acceptable and desirable.