I have some old code that I would like to test using Junit. After importing it into Eclipse it looks like this:
After this, I try to test the class ACos. I've entered some values, but it doesn't work. I get this:
What have I done wrong?
Looks like your class under test is in the main package (= ""). Try without jscicalc.pobject.
Correction: If pobject is supposed to be the package, you should set it as source folder. (Right-click -> Build path on it).
Your Java code should be under the src folder and not the pobject folder.
It probably needs to be in a package as well, but that's not as easy to tell without seeing the code within it. It should also be obvious with the errors that occur when moving it.
Related
I have been working on a extension for Visual Studio Code (v1.15.0). It contains commands (functions) to change HTML code in the VSCode editor window, for code conversion purposes.
I decided to extend my unit test code with an test-data.html file. So the test are running on a prepared HTML document, to test the commands and results.
My launch.json file, contains something like
... "args": ["${workspaceRoot}/test/test-data.html", "--extensionDevelopmentPath=${workspaceRoot}", "--extensionTestsPath=${workspaceRoot}/out/test" ], ...
Everything works fine, except for the fact that after the test (with tested code changes), the test file is saved. Ruin the original test data set.
I would like to disable the auto save in the 'Extension Development Host' environment, when my test are run. Can we do that or maybe, introduce a couple of undoes?
Or create a copy in the ./out folder and use that? Then how to do that.
Aug. 18, additional note
It's a strange problem. I'm working on this project at home and at work. Different machines. VSC is same version, maybe different extensions.
This problem of compromising my original test data, occurs only when working at Home. On the work PC everything works as expected, test data stays as it is.
Maybe something like 'auto save', I need to investigate.
Sep. 8, additional note
Nailed it, it was the 'Auto Save' option turned on. Not sure why it was set. Problem solved (I also implemented a copy function, which solved the problem also).
Use fs-extra to copy your test-data.html file to the out folder and then use the same command you used to load it, just change /test to /out.
In my project directory, there are two folders named as follows:
./.repl-1.7.170
./.cljs_node_repl
I believe these folders are automatically generated. What are they for? Is it OK to delete them periodically when cleaning up?
I think these are both working directories used by the REPL when compiling REPL-related code.
In either case, why do you need to delete them?
The only consideration around this I can think of is wanting to make sure they don't somehow get committed to source code control. For that you can just use ignores or excludes if for example, you are using git.
In my application I maintain the 'user-frendly' version as a public String constant in the main class.
Is it possible to retrieve this variables in the build.gradle to set the version property of the project? Currently I have to do this manually, what of course can lead to problems.
Correct way of maintaining "user-friendly" version would be version.properties file, stored in your source tree. E.g., under src/main/resources. Then you can load this properties file in Gradle script:
def config = new ConfigSlurper().parse(new File("src/main/resources/version.properties").toURL())
println(config.versionNumber)
I've plussed Nikita's answer, which is great.
But, firstly, File.toURL() is now deprecated. Something like this would be preferable:
ConfigObject conf = new ConfigSlurper().parse( file("src/main/resources/version.properties").toURI().toURL());
Secondly, note file( ... here, not new File( ... if this line is to be included in build.gradle. The former makes a File relative to the path of the root directory of your Gradle project and is in fact a method of Gradle interface Project. It's worth knowing that every method or property in build.gradle which appears to "come from nowhere" is in fact a method or property of an underlying, "invisible" Gradle Project instance.
If you put new File( "src/main... ") in build.gradle as in Nikita's answer you would in fact not notice any problems if running your Gradle task from a console with current directory the project/root directory... but (according to my experiments) if using the GradleTasks window in Eclipse, for example, you would then be creating a File path relative to the directory where Eclipse was running from... and this would give an error message saying "system cannot find the path specified".
Using file( ..., therefore, you can then go (in build.gradle):
version = conf.versionNumber
NB version here is another property of Project... but you'll be mystified if you look at the above Javadoc for Project, because it's not there! However, you will see getVersion() and setVersion(...). With Groovy every property automatically gets given, by Groovy magic, its own getter and setter method. I took a week out to learn a bit of Groovy, which is actually a fantastic language, and familiarising yourself with it a bit is highly recommended, and makes the learning curve of Gradle substantially less painful.
You can however find the version property in the DSL (domain-specific language) API for Gradle class Project here.
The file version.properties would typically contain something like this:
versionNumber='1.0.0'
NB accessing version from your code ... if you wanted to access this version number from your app code (or test code), you would indeed use new File( ...:
ConfigObject conf = new ConfigSlurper().parse( new File("src/main/resources/version.properties").toURI().toURL());
as in Nikita's answer.
Context
I am working on a klee (http://klee.llvm.org) fork and want to clean up our repository to separate our stuff from the "canonical" klee code. Anyway, I'm having trouble understanding/extending the build system.
Problem
The directory structure in /lib/ looks like this
Basic/
Core/
Support/
Expr/
Solver/
Module/
Mine/
Mine was just added by me, so far we threw everything in Core and I am moving it to Mine. How do I tell the build system to do this properly?
My attempt
Being unable to figure this out on my own, I edited /lib/Makefile:
LEVEL=..
PARALLEL_DIRS=Basic Support Expr Solver Module Core Mine
include $(LEVEL)/Makefile.common
and copied the /lib/Core/Makefile to /lib/Mine/Makefile while changing LIBRARYNAME=kleeCore to LIBRARYNAME=kleeMine.
Caveat
I have a feeling that this is not the proper way to do it, and I should rather modify some configure script or something. Also it does not link (it compiles, though).
A colleague just told me how to get it to link, which is by modifying /tools/klee/Makefile
USEDLIBS = kleeCore.a kleeModule.a kleaverSolver.a kleaverExpr.a kleeSupport.a kleeBasic.a kleeMine.a
Things were running fine. Who knows what changed, but now I end up with:
Unit Test Runner failed to load test assembly:
JetBrains.Resharper.TaskRunnerFramework.TaskException:Exception of type 'Microsoft.VisualStudio.TestTools.CommandLine.CommandLineParameterException' was thrown.
Any suggestions?
I've just been having the same problem. It turned out that the Solution Items "folder" had a couple of .testsettings files in it which didn't actually exist (probably because they weren't added to the Git repo). Anyway, I removed them from the Solution and the R# runner now works fine.
Hope that helps.
You can check here for R# bugs that have the same description and maybe find the cause of your problem or a possible workaround. This bug seems to come close.
The other answers did not work for me unfortunately, instead I had to create a testsettings file manually to resolve the issue:
Right click Solution root
Add > New Item...
Select Test Settings from the Installed Templates column
Select the Test Settings item, and rename to the desired file name as necessary
Add
You should now be able to run your unit tests correctly.