Skip to content

Commit

Permalink
Merge pull request #136 from sta-szek/#113-Testing-constructors
Browse files Browse the repository at this point in the history 
#113. Constructor testing
  • Loading branch information
Piotr Joński authored Oct 10, 2016
2 parents b9bda55 + 2edb2fa commit c0e3019
Show file tree
Hide file tree
Showing 270 changed files with 78,916 additions and 40,537 deletions.
1 change: 0 additions & 1 deletion build.gradle
View file
Original file line number Diff line number Diff line change
Expand Up @@ -164,7 +164,6 @@ static def gitUser() {
username + " " + useremail
}

assemble.dependsOn javadoc
check.dependsOn jacocoTestReport
build.dependsOn publishToMavenLocal

35 changes: 20 additions & 15 deletions docs/comparison/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Here you can compare pojo-tester to existing java libraries that test `pojo-meth
## Other libraries {#other-libs}
Here is the list of libraries that were found on the Internet. If you find another one, feel free to write a comparison and include it into your pull request.

* pojo-tester 0.4.0
* pojo-tester 0.5.0
* [openpojo](http://openpojo.com) 0.8.4
* [SmartUnit](https://github.com/rlogiacco/SmartUnit) 0.10.2
* [testUtils](http://outsidemybox.github.io/testUtils/index.html) 0.1.3
Expand Down Expand Up @@ -40,26 +40,27 @@ Each library provides different testing features. Here is the comparison.

Basic `pojo-methods` test support:

| Kind of tests | pojo-tester | OpenPojo | SmartUnit | testUtils | testUtil | Mean Bean |
|--- |:---: |:---: |:---: |:---: |:---: |:---: |
| getters | &#10003 | &#10003 | &#10003^ | &#10003 | &#10003^ | &#10003 |
| setters | &#10003 | &#10003 | &#10003^ | &#10003 | &#10003^ | &#10003 |
| equals | &#10003 | &#10003*^ | &#10005 | &#10003 | &#10005 | &#10003^ |
| hashCode | &#10003 | &#10003*^ | &#10005 | &#10003 | &#10005 | &#10003^ |
| toString | &#10003 | &#10003*^ | &#10005 | &#10003 | &#10005 | &#10005 |
|||||||||
| Additional features ||
| Kind of tests | pojo-tester | OpenPojo | SmartUnit | testUtils | testUtil | Mean Bean |
|--- |:---: |:---: |:---: |:---: |:---: |:---: |
| getters | &#10003 | &#10003 | &#10003^ | &#10003 | &#10003^ | &#10003 |
| setters | &#10003 | &#10003 | &#10003^ | &#10003 | &#10003^ | &#10003 |
| equals | &#10003 | &#10003*^ | &#10005 | &#10003 | &#10005 | &#10003^ |
| hashCode | &#10003 | &#10003*^ | &#10005 | &#10003 | &#10005 | &#10003^ |
| toString | &#10003 | &#10003*^ | &#10005 | &#10003 | &#10005 | &#10005 |
| constructors | &#10003 | &#10005 | &#10005 | &#10005 | &#10005 | &#10005 |
||||||||
| Additional features |
| field selection | &#10003 | &#10003 | &#10003 | &#10003 | &#10005 | &#10003 |
| method selection | &#10003 | &#10003 | &#10005 | &#10005 | &#10005 | &#10003 |
| supports nonpublic classes | &#10003 | &#10003 | &#10005 | &#10003 | &#10005 | &#10005 |
| supports non-default constructors | &#10003 | &#10003 | &#10005 | &#10003 | &#10005 | &#10005 |
| recurrence support | &#10003 | &#10005 | &#10005 | &#10005 | &#10005 | &#10005 |
| creating object by user defined constructor | &#10003 | &#10005 | &#10005 | &#10005 | &#10005 | &#10005 |
| custom changing fields values | &#10003 | &#10005 | &#10005 | &#10005 | &#10005 | &#10005 |
| package-testing | &#10005 | &#10003 | &#10005 | &#10005 | &#10005 | &#10005 |
| package-testing | &#10003 | &#10003 | &#10005 | &#10005 | &#10005 | &#10005 |

\* limited support for changing fields recursively and otherwise having problems with fields other than primitives.
Libraries throw exceptions from java core, which does mean nothing.

^ requires additional changes in your production code

### Tests
Expand Down Expand Up @@ -280,9 +281,6 @@ And there is one more thing. Tests (internal, in library implementation) using M
`POJO-TESTER` does the job. It provides stable coverage with the highest percentage. See numbers below.
![](coverage-comparison.png)

Next thing that `POJO-TESTER` can do, but other libraries cannot, is recursively testing fields.
This means your tests are more sure.

We have done one more code coverage report using changing nested fields.
From those tests we excluded three libraries - Mean Bean, Smart Unit and TestUtil.
They simply could not perform such tests and threw undefined exceptions.
Expand Down Expand Up @@ -316,4 +314,11 @@ Disadvantages are:
* it has variable coverage report, which can cause unwanted CI reports
* it does not support recurrence which can be a deal breaker, especially if you use enums or VOs (Value Objects)

Next thing that `POJO-TESTER` can do, but other libraries cannot, is recursively testing fields.
This means your tests are more sure.

And last but not least which makes `POJO-TESTER` awesome is that it can test constructors!
Now you can forget about getting constructors via reflection, invoking them... What a nightmare. And who is doing this?
No more reflection in your tests!

To sum up, `POJO-TESTER` has the highest consistent coverage and its features make your tests more bulletproof.
Loading

0 comments on commit c0e3019

Please sign in to comment.