I am trying to run the unit test cases written in go lang. While executing the test cases, i am getting error like "%1 is not a valid Win32 application".
I have already tried re-installing go, but still the problem persists.
go.exe test dir -run ^(testname)$
fork/exec C:\user\username\AppData\Local\Temp\go-build976684114\packageName.test: %1 is not a valid win32 application.
Error: Tests failed.
The above mentioned folder is not created as well. Not sure, what is happening.
if i set my GOOS to windows it is working
set GOOS=windows
If go env GOOS produces a different operating system than your own, then you can restore it to its default value by unsetting the environment variable GOOS.
The same applies for GOARCH and any plattform-specific variables, such as GOARM.
try restarting your PC!!!
I don't know exactly but this may cause because by temporary files clashing with your go instance
Related
Currently the only thing I can see is the executable exit code, so I can see if any tests failed or not, but I don't get any other output.
Is there a way to show something similar to what you see in Qt Creator when running tests?
I am using CMake and the Qt Test framework.
You can use -junitxml option to output test results to xml file(s) and use one of actions to watch detailed reports:
action-junit-report
publish-unit-test-results
junit-report-action
test-reporter
report-junit-annotations-as-github-actions-annotations
I figured out a workaround. If you use the -o filename,format command line argument and output to a file, you can then use more filename to get the Test results.
GitHub actions uses Windows Server as the environment so that might be a reason for the weird behavior. My best guess is the Qt implementation works differently on Windows Server, because std::out works fine.
I've been doing some thunderbird develop lately, and wanna do some unit test for my XPCOM module. I notice that there is a tool called mach in mozilla which can automatically run a set of test cases at one time, but when I run "mach help" on windows, It shows that "is_platform_supported - Must have a Firefox, Android or B2G build."
Since I'm using thunderbird, does that mean that I can't use mach for unit test for thunderbird? If not so - which I hope - how can I change my config to use that tool?
Any reples from you will be appreciated!
Thanks in advance.
At the moment, mozilla/mach xpcshell-test does not work (see Bug 934170). As a workaround, use the following:
First, switch to the object directory after building Thunderbird.
To run all xpcshell tests, use: make xpcshell-tests
To run a single xpcshell test, use (e.g.): make xpcshell-tests TEST_PATH=mailnews/news/test/unit/test_server.js
To run all xpcshell tests in a given directory, use (e.g.): make xpcshell-tests TEST_PATH=mailnews/news
I am running tests through Jenkins on a windows box. In my "Execute Windows Batch command" portion of the project configuration I have the following command:
nosetests --nocapture --with-xunitmp --eval-attr "%APPLICATION% and priority<=%PRIORITY% and smoketest and not dev" --processes=4 --process-timeout=2000
The post build actions have "Publish JUnit test result report" with the Test report XMLs path being:
trunk\automation\selenium\src\nosetests.xml
When I do a test run, the nosetests.xml file is created, however it is empty, and I am not getting any Test Results for the build.
I am not really sure what is wrong here.
EDIT 1
I ran the tests with just --with-xunit and REM'd out the --processes and got test results. Does anyone of problems with xunitmp not working with a Windows environment?
EDIT 2
I unstalled an reinstalled nose and nose_xunitmp to no avail.
The nosetest plugin for parallelizing tests and plugin for producing xml output are incompatible. Enabling them at the same time will produce the exact result you got.
If you want to keep using nosetest, you need to execute tests sequentially or find other means of parallelizing them (e.g. by executing multiple parallel nosetest commands (which is what I do at work.))
Alternatively you can use another test runner like nose2 or py.test which do not have this limitation.
Apparently the problem is indeed Windows and how it handles threads. We attempted several tests outside of our Windows Jenkins server and they do not work either. Stupid Windows.
Just installed Android Studio to give it a try. I'm trying to create a test module for my application and, whatever the method I use, I always get the following error: "Error: No AndroidManifest.xml file found in the main project directory...".
Methods I use:
1) from Android Studio: New > Module > Test Module
2) from command line: android create test-project -m "main_path" -n "project_name" -p "test_path"
Any ideas on how to solve this?
Edit: As of 0.1.8 this is now supported in the IDE.
According to the documentation for the new build system a separate project is no longer needed, which implies that a separate module may not be either. That said, getting test working within the IDE is still problematic. I've posted an answer here that at least works for running tests from the command line.
I am busy converting by existing firebreath plugin here to use gpgme instead of making calls via the OS and the gpg binary.
I have managed to get the code to compile in windows using VS 2010 on a x32 system but after loading the plugin into chrome I can not access the npapi code at all. Even simple version calls fails.
When loading the plugin I get no visible errors but when using sawbuck log viewer for chrome I get the erorr messages below.
.\renderer\webplugin_delegate_proxy.cc 347 PluginMsg_Init returned false
..\plugins\npapi\webplugin_impl.cc 271 Couldn't initialize plug-in
I have tried to use my code with both firebreath 1.4 and 1.6 and neither versions work. After some simple debugging it seems that using any code provided by gpgme (whether its called or not) causes the plugin to break.
I came to this conclusion by doing the following.
Created a new project with firebreath (versions 1.4 and 1.6)
Add the gpgme.h headers to gmailGPGAPI.cpp and changed nothing else aside from adding the required reference paths to the project.
Build the project to create the dll (this generates the dll fine).
Replace the existing ddl in my project with the dll in step 2 and test it with the following piece of code
plugin = document.createElement('object'); plugin.id = 'plugin';
plugin.type = 'application/x-gmailtest';
document.body.appendChild(plugin);
console.log("my plugin returned: "+ plugin.valid);
console.log("my plugin returned: " + plugin.version);
This returns valid = true and the version returns what ever i set it to.
I then modified gmailGPGAPI.cpp to now return the gpg version by calling gpgme_check_version(NULL) in the version method. I used that method because its probably the simplest returning function that I could test with.
Build the plugin and copy dll to chrome extension as in step 3-4. The plugin builds fine again as expected.
Load the plugin and try to execute the code in step 4 at which point it now just returns undefined for any property or method i try to access on the plugin. No errors are printed to the console or anywhere else in chrome except for the error logged to sawbuck.
I have got no idea where to look or what to try since I cant seem to get an actionable error to work against. I have also reduced by test code to the point where its just a new project with a one line change to make it easier to find the problem.
I should note the code in the repo builds fine in linux/OSX and loads into chrome correctly so I know at some level my code does work.
Two possible paths:
You may have a DLL dependency that isn't available which keeps the plugin from loading; if you run regsvr32 on it in the state where it doesn't work on chrome, does it work?
Your plugin may be loading and then crashing. Start chrome with --plugin-startup-dialog and then when it pops up a dialog warning you that a plugin is about to be loaded attach to that process and see if the process crashes. At this point you can also set breakpoints to try to figure out how far it gets.
Double check your metadata in PluginConfig.cmake as well; sometimes unusual characters in some fields can cause issues like this.