I am trying to create tests on core java application/classes , but i am getting the following error:
java.lang.NoClassDefFoundError: Could not initialize class oshi.software.os.windows.WindowsOperatingSystem
at oshi.SystemInfo.createOperatingSystem(SystemInfo.java:102)
at oshi.util.Memoizer$1.get(Memoizer.java:84)
at oshi.SystemInfo.getOperatingSystem(SystemInfo.java:95)
at com.diffblue.cover.analytics.system.SystemTags.getUserOS(SystemTags.java:71)
at com.diffblue.cover.analytics.system.SystemTags.create(SystemTags.java:40)
at com.diffblue.cover.analytics.api.TelemetryEventFactory.create(TelemetryEventFactory.java:34)
at com.diffblue.cover.analytics.api.TelemetryEventFactory.create(TelemetryEventFactory.java:50)
at com.diffblue.cover.api.Cover.run_aroundBody0(Cover.java:382)
at com.diffblue.cover.api.Cover.run_aroundBody1$advice(Cover.java:126)
at com.diffblue.cover.api.Cover.run(Cover.java:1)
at com.diffblue.intellij.plugin.actions.BackgroundAnalysisWrapper.run(BackgroundAnalysisWrapper.java:330)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:888)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:163)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:585)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:531)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:59)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:150)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.lambda$run$0(CoreProgressManager.java:402)
at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:221)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:402)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:238)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Hi @neeloupfhars thanks for the report. We discovered a packaging issue which may be responsible for the problems that you are seeing and which we have resolved in 2020.11.03 which was published a couple of hours ago. If you are not using this version please could you update and retry? If you are using this version then please can you provide some more information about your environment and the type of code you are wanting to generate tests for?
java.lang.UnsatisfiedLinkError: Failed to create temporary file for /com/sun/jna/win32-x86-64/jnidispatch.dll library: The system cannot find the path specified
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1032)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.(Native.java:195)
at com.sun.jna.Memory.malloc(Memory.java:722)
at com.sun.jna.Memory.(Memory.java:114)
at com.sun.jna.platform.win32.Advapi32Util$EventLogIterator.(Advapi32Util.java:2480)
at oshi.software.os.windows.WindowsOperatingSystem.querySystemBootTime(WindowsOperatingSystem.java:671)
at oshi.software.os.windows.WindowsOperatingSystem.(WindowsOperatingSystem.java:91)
at oshi.SystemInfo.createOperatingSystem(SystemInfo.java:102)
at oshi.util.Memoizer$1.get(Memoizer.java:84)
at oshi.SystemInfo.getOperatingSystem(SystemInfo.java:95)
at com.diffblue.cover.analytics.d.a.d(SourceFile:71)
at com.diffblue.cover.analytics.d.a.a(SourceFile:40)
at com.diffblue.assertion.a.a.a.a(SourceFile:1034)
at com.diffblue.cover.api.Cover.a(SourceFile:3050)
at com.diffblue.cover.api.Cover.run(SourceFile:1)
at com.diffblue.intellij.plugin.actions.a.run(SourceFile:330)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:888)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:163)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:585)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:531)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:59)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:150)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.lambda$run$0(CoreProgressManager.java:402)
at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:221)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:402)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:238)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Hi @neeloupfhars so sorry to see you are still having problems.
It looks like you are on Windows and our internal testing on Windows does not show this problem, so we need to work out what’s different about your setup.
The trace you are seeing is for a piece of third party code that uses a native library to determine platform information. We have checked that the library in question is being shipped (it is) so it must be something to do with the availability of the library - either its incompatible with your environment or the system cannot get at it.
So to dig a little deeper, please could you provide the following information:
What version of Windows are you testing on (including patch level please)?
What version of IntelliJ are you using?
What directory is IntelliJ installed in?
What version of Java are you using? (including patch level please).
Do you have any restrictions in your environment that might prevent the writing of temporary files, e.g. a virus scanner or similar?
We are trying to recreate this in our environment - so far without success. Is there anything special about your environment, for example is it an enterprise managed device which has restrictions on it?
Hi @neeloupfhars, thanks for checking for us; we haven’t seen this before so we are really keen to get to the bottom of the problem here - you are a great help
Yes the plugin works with pure Java and Spring Java
Hi @neeloupfhars we are not exactly sure what is going on in your environment, but we are going to remove this native code dependency as its not really required.
Without using reflection, both human developers and Diffblue can only write unit tests for accessible methods.
Protected methods should be being tested - are you not seeing tests for these?
Private methods are not directly accessible by unit tests as they are in a different class; we rely on the unit tests for these public methods to exercise the private methods which they call.
Using Reflection in unit tests has a couple of problems:
Tests using Reflection can be quite fragile - the unit test ends up testing not just the behaviour of the code under test, but also to a large extent the precise naming/structure of elements of the code. This can often mean that fairly trivial changes made by a programmer, such as renaming a private field, can cause failures in your unit tests.
It changes the nature of unit tests from being a test of the externally visible behaviour of your class/methods, into a ‘white box’ test of the exact implementation details. This is often considered to be against Test Driven Development goals, for instance.
Tests using reflection are often hard to read and understand Which means that when they fail, they are often harder to fix.
Of course, sometimes people really do want to test a private method in isolation and they resort to using reflection. However, its often possible to reconsider the architecture of such a class or method to make it easier to test without reflection.
It would be great to understand more about what you are looking to test and of course we would be really happy to help answer any further questions you have
Which means that when they fail, they are often harder to fix.