Timeline for Does it make sense to measure conditional coverage for Java 8 code?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 8, 2016 at 7:43 | history | tweeted | twitter.com/StackSoftEng/status/806766246704254977 | ||
| Dec 2, 2016 at 16:05 | history | edited | Karol Lewandowski | CC BY-SA 3.0 |
deleted 20 characters in body; edited title
|
| Dec 2, 2016 at 14:10 | comment | added | kdgregory | I'm going to repeat my earlier point: that's always the case, unless you limit yourself only to basic language features and never call any function that hasn't been instrumented. Which means no third-party libraries, and no use of the SDK. | |
| Dec 2, 2016 at 14:09 | comment | added | Andy | I am voting to close this question in its current format, because it's a request for recommended tools/libraries to measure logical branches. | |
| S Dec 2, 2016 at 11:34 | history | suggested | Cedric Martens | CC BY-SA 3.0 |
fixed grammar
|
| Dec 2, 2016 at 5:18 | review | Suggested edits | |||
| S Dec 2, 2016 at 11:34 | |||||
| Dec 1, 2016 at 22:20 | comment | added | Karol Lewandowski | I'm saying that there are no tools (to my knowledge) providing me with information what I missed in my tests. Existing tools base on "technical" branches like if/case/loops and don't care about lambdas cooperating with new Java 8 objects what reduces most of old null-checks. I know that it's possible to make them provide the same information again (by modifying bytecode to put "checkpoints" in lambdas), but if it hasn't been done yet, I doubt anyone plans to do it (and I can't understand why). | |
| Dec 1, 2016 at 22:09 | answer | added | Shaz | timeline score: 4 | |
| Dec 1, 2016 at 22:02 | comment | added | JimmyJames | Wait, is is that there's only one line with multiple branches and these tools focus on lines, right? I get it. In theory, the branches are still traceable in the bytecode. The tool would have to be updated to support showing that say only 2/3 branches in that line were covered. Is that it? | |
| Dec 1, 2016 at 22:00 | comment | added | JimmyJames | It's not clear whether you are saying that the tools you used before for sure don't work or whether you are asking if they will still work. Most of these tools look at the bytecode and I don't think it was necessary to introduce new bytecode to support these features. Can you clarify? | |
| Dec 1, 2016 at 21:47 | history | edited | Karol Lewandowski | CC BY-SA 3.0 |
added 12 characters in body
|
| Dec 1, 2016 at 21:44 | comment | added | Karol Lewandowski | Before Java 8 I had little friend telling me what I missed in my tests and when Java 8 came my friend retired. Currently nothing supports me to find undertested contracts and I need to do it on my own which is not easy task. I always preferred to delegate work to tools/people that do it better than me and to have less things to care about. | |
| Dec 1, 2016 at 21:42 | comment | added | Karol Lewandowski | Again, I'm not saying that coverage proves my code is perfectly tested, but it was EXTREMELY valuable tool showing me what I haven't tested for sure. I think that testing contracts is inseparable from testing execution paths (your example is exceptional as it involves implicit language mechanism). If you haven't tested path, then you haven't fully tested contract or contract is not fully defined. | |
| Dec 1, 2016 at 20:32 | comment | added | Vincent Savard |
Coverage is worth what's it's worth. You have the same issue with int add(Integer i, Integer j) { return i + j }. You can easily have 100% coverage by testing add(new Integer(1), new Integer(2)) == 3, but coverage still won't tell you that add(new Integer(1), null) fails. Actually, you just exposed the problem with coverage: just because you covered it with tests doesn't mean you tested it correctly, and relying on that lulls you into a false sense of confidence.
|
|
| Dec 1, 2016 at 20:29 | comment | added | Vincent Savard |
What's the contract of getName? It seems to be that if user is null, it should return "unknown". If user is not null and user.getName() is null, it should return "unknown". If user is not null and user.getName() is not null, it should return that. So you would unit-test those three cases because that's what the contract of getName is about. You seem to be doing it backward. You don't want to see the branches and write the tests according to those, you want to write your tests according to your contract, and ensure the contract is fullfilled. That's when you have good coverage.
|
|
| Dec 1, 2016 at 20:13 | comment | added | Karol Lewandowski | Of course high conditional coverage doesn't mean that we have good tests, but I think that it's HUGE advantage to know which execution paths are uncovered and this is what the question is mostly about. Without conditional coverage it's much harder to spot untested scenarios. Regarding paths: [user:null], [user:notnull, user.name:null], [user:notnull, user.name:notnull]. What I'm missing? | |
| Dec 1, 2016 at 20:00 | comment | added | kdgregory | Coverage metrics have never been a good way to determine whether your code is well-tested, merely a way to determine what hasn't been tested. A good developer will think through the various cases in her mind, and devise tests for all of them -- or at least all that she thinks are important. | |
| Dec 1, 2016 at 18:48 | review | Close votes | |||
| Dec 8, 2016 at 3:01 | |||||
| Dec 1, 2016 at 18:19 | history | asked | Karol Lewandowski | CC BY-SA 3.0 |