I'm not sure if this question is going to be closed due to it being too novice but I thought I'll give this a shot anyway.
I am currently working on a Selenium Automation framework which, though seemingly well built, is running it's code by spawning threads. (The framework is proprietary so I'm unable to share the code)
This framework instead of using a Test Framework like JUnit or TestNG to run "Tests", uses a threaded approach to run. aka, the methods that read datasheet, instantate and execute the Drivers, report the results etc. them are executed by starting a thread, the class of which is instantiated at various places in the code on runtime.
My concern is: though it runs fine locally with providing the reports and what have you, what it would be unable to do, due to it not operating using a Test Runner, it's unable pass or fail a "Test".
Therefore, on putting this up on a build pipeline, "Test"s wouldn't be executed as there are no "tests" so to speak, thereby making it making it lose it's juice on CI/CD as far as reporting of build pipeline success or failure is concerned.
Am I justified/unjustified in my concerns? Why? And is there a workaround for this? At what ROI?
Resources or links shall be welcomed and beer shall be owed!! :-)
Cheers,
Danesh
Related
I am automating some software testing using Jenkins on our in-house test software. It is written in C# with WPF. I am using the version of the program that has no frontend, but it still makes calls to WPF in order to start the service. The test application is launched through python scripts using subprocess.Popen
When running under the Jenkins slave process I get the following error:
Unhandled Exception: System.ComponentModel.Win32Exception: The operation completed successfully
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
...
From my research it seems that something is going wrong with the windows atom tables. The weird thing is that I don't run into the same issue when running the python scripts as a local user, it only crashes when it is the Jenkins service running the scripts.
Is there some limitation on the local atom table for windows services?
Is Jenkins hogging atom table entries?
Update 1:
I did some more research on the crash and some resources said for WPF there might be a windows handle leak, so I inserted some power shell calls to check how many active handles there are on the system.
It doesn't look like there is a handle leak from any of the software under test, I am seeing around 50-60k handles while jenkins is running the test scripts, which is consistent with what I was seeing while running it under my user account. It looks like Jenkins is interfering with WPF's ability to construct the program (The full callstack for the error is on the Main() constructor), but I have no idea why it would be doing that.
Update 2:
Some extra information since I think it is relevant, here is the full call stack:
Unhandled Exception: System.ComponentModel.Win32Exception: The operation completed successfully
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
at System.Windows.Threading.Dispatcher..ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.Application..ctor()
at <TestingApplication>.ScriptHost.App..ctor()
at <TestingApplication>.ScriptHost.App.Main()
So what appears is happening is the following:
Jenkins calls the python scripts. They perform setup and all pre-condition work such as bringing up the software under test
Python calls the TestingApplication through Popen
The executable starts and attempts to construct the application
WPF checks to see if there is a Dispatcher already on the thread, there is not
WPF attempts to create a Dispatcher since one doesn't already exist
Crash because a Dispatcher cannot be created
Again, this only happens when launched under the Jenkins service user.
So here's what I did to fix the problem:
The software under test also uses WPF to create the displays, so I wanted to see if maybe i'm running out of resources by having too many things open. There are 5 SUT applications. Luckily, one of the pieces of software we run is a console that I don't need open when running tests through Jenkins. Thus I was able to not launch the console application and that freed up enough resources for the test application to run.
What this doesn't answer is:
Why do I have less resources on a service compared to a regular user?
Is this because of Jenkins/Python or because of Windows?
Is there a workaround for this problem?
Those questions could be asked outside of this question so I am answering just so that it is available to someone with a similar problem and to close it. For someone who doesn't have the luxury of closing extra applications, I would ask those questions yourself.
We added new features to our data collection mobile application after two -three months of inactivity, only for the build to keep failing.
This is the stack trace
ll-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
1 error; aborting
:transformClassesWithDexForRelease FAILED
:transformClassesWithDexForRelease (Thread[Daemon worker,5,main]) completed. Took 11.045 secs.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':transformClassesWithDexForRelease'.
> com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.ide.common.process.ProcessException: Error while executing java process with main class com.android.dx.command.Main with arguments {--dex --verbose --force-jumbo --num-threads=4 --output /tmp/build8570106392456281219xxx/Application/build/intermediates/transforms/dex/release/0 --min-sdk-version 15 /tmp/build8570106392456281219xxx/Application/build/intermediates/transforms/proguard/release/0.jar}
You or one of the cn1libs you are using included a javax.xml package as part of the code. We migrated to build target 27 over the weekend and I'm guessing that Google made checks for this sort of problem more rigid.
I see a lot of keep statements in your build hints so I'm guessing this was done intentionally.
I'm trying to debug an issue that happens on service startup. Trying to attach while things are running is failing, windbg times out with an error about a link lock. I think that the error occurs before I have a chance to attach. A sleep might let me attach, but is there a more elegant solution?
I'd like to start up the debugger first thing as the service starts. C# has a Debugger.Launch() method to start a debugger at runtime. Is there an equivalent C call that can be used without .net? Something I could just drop in the start routine.
I can't call DebugBreak because at the time the service has started I'm not under a debugger.
Sleep is certainly a viable approach. It's crude yet effective. Somewhat less crude is to use a good logging framework to output diagnostics. With a sufficiently capable logging framework this can be very effective.
I am using KIF to test my application. I want to start my tests from command line, I looked into the tool WaxSim, looks like it's for running the tests on a simulator. But is there a way to use KIF tests in continous Integration with the real device. It would be helpful if I can invoke the tests from command line which run in a real device.
I know it is possible to do this with apple UI automation on ios5 beta version, but let me know if there is a way to do this in ios4.
Your help will be much appreciated.
-Teja
From the KIF google group
Right now, no, there isn't. Are there any particular device-only needs you have, or is it just on general principle? We're looking in to a way of doing device tests in CI, but it's a tough nut to crack. All of the frameworks for controlling devices are private.
I am kind of lost here, and I don't know what to do
I have a problem that I don't know what the source of it.
We have a large wpf application, that is built similar to prism (composite application)
Actually we are using lots of prism library.
I wrote a module to replace an existing module.
And the application now is loading my module, instead of the old module.
I start to notice, with the new module, that sometimes the application freeze for 20-30 seconds without any response, and then it work smoothly after that.
The freeze is not consistent, and there is no pattern or a specific reason that cause it.
I am suspecting that could be my module that is causing that freeze.
But at the same time, many other developers introduced new code to the application.
My question is there a way to trace that freeze?
Is there a way to compare the old module and the new module that I wrote?
I can run the application with my module, and trace the application, and then I can change the config file to load the old module.
Is there a way to compare between the two?
Should I do profiling?
and if profiling will help, then what should I look for?
any other tool could help?
Thanks a lot for any reply
It sounds like you are doing a long running operation on your UI thread. Are you making any database / webservice calls from the main thread? I think one of the easiest things to do is run it in the debugger, and when it freezes, hit the "pause" button. Visual Studio will pause execution at the current location, and you can examine what is taking so long.
If the problem isn't immediately obvious there, I would definitely start profiling the application to track this down.