Is it possible to configure SBT so that only the logs for failing tests are displayed to the console?
It'd avoid to have too much information in general in the output and to be able to concentrate on failing tests.
Related
I have reportportal installation running on Windows box. I am planning to use it as dashboard to look at unit test and other automated test results. I understand reportportal integration with unit test frameworks is done at the logger level so that the test app itself can send results back to dashboard.
I have a scenario where the test application is an exe that I want to launch by sending a command from dashboard to system under test.
Are there any provisions for doing it?
Do I have to build an agent that talks to reportportal using its api for this?
Thanks
No, nothing similar at the moment.
It is pretty popular request, so we have it in backlog, but still focus on test reports aggregations first. And the other types of functionality will come later.
We have a test suite that runs 30 or more minutes and it is not uncommon for me to see a situation like this:
I don't generally want to break on a first failure (--stop-on-failure) but in this specific example, I also don't want to wait another 10-15 minutes for the test suite to finish. If I do Ctrl+C, the process stops immediately and I won't see any messages.
I'm specifically interested in the format that PHPUnit uses in the console which I find very useful. For example, logging to a file using --testdox-text produces a nice but not very detailed list. Logging with --log-teamcity is verbose and quite technical.
Is there a way to see "console-like" PHPUnit messages before the test suite fully finishes?
Update: I've also opened an issue in the official repo.
maybe you could register a listener in your phpunit.xml file and implement its addFailure() method to display some info in console or a file...
I am trying to run my Automated test cases deployed on a virtual machine and trying to trigger it with the help of Octopus Deployment tool. I installed test agent and Octopus Tentacle on my machine. Octopus is triggering the DLL's for Automated test cases very well.But while Octopus trying to run the test cases it's giving me an Error as below:-
Microsoft.VisualStudio.TestTools.UITest.Extension.UITestException: To run tests that interact with the desktop, you must set up the test agent to run as an interactive process. For more information, see "How to: Set Up Your Test Agent to Run Tests That Interact with the Desktop" (http://go.microsoft.com/fwlink/?LinkId=255012)
Error 01:59:38
If you are running the tests as part of your team build, you must also set up the build agent to run as an interactive process. For more information, see "How to: Configure and Run Scheduled Tests After Building Your Application" (http://go.microsoft.com/fwlink/?LinkId=254735)
I setup my password in test agent and set it as intractive process but still i am facing the same issue.
I am triggering my DLL's as below through Octopus.
& "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "C:\MyWebaPP\Automated_test\Automated_test.dll"
I tried each and every way i found.Please help me out in this.
Thanks in advance!!
We recently encountered the same problem.
During our research, we found this post on the Octopus support forum:
http://help.octopusdeploy.com/discussions/questions/5080-tentacle-running-interactive-tests
We also contacted Octopus Deploy by mail, and they essentially gave us the same response.
While we had no luck with the "scheduled task for test run" approach, we eventually managed to get it working by running the Octopus Tentacle as a process rather than a service.
The challenge here was making sure the Tentacle would start when our test machine started. We wanted this to happen automatically, so RDPing in and starting the process every time was out of the question (this also caused some additional problems for the UI test run...).
The final working solution was to schedule a task that would start the Octopus Tentacle as an interactive process whenever the machine booted (i.e. run Tentacle.exe directly), and then make sure we never RDP to this machine. Make sure the task has sufficient privileges, and that it "Runs whether the user is logged in or not". Also, remember to disable automatic startup of the Octopus Tentacle Service.
Edit: We had some trouble making this solution work across all our environments. It seems that for security reasons, newer versions of Windows are quite skeptical about allowing scheduled tasks to start interactive processes when there is no user logged on.
We did another search for possible solutions, and came across FireDaemon Pro (commercial software), which allows us to register interactive Windows services that run under a domain user. Not quite sure how it works, but they seem to be able to run a UI from a Windows service in session0 (the UI is also isolated). The Octopus Tentacle starts without complain, and the UI tests run the way we want them to.
I've moved my grunt job into Bamboo and everything works great except for the dust compiler. All of my other tasks in my gruntfile can be targeted from the bamboo task and they work. The dustc task gives this error when run: Fatal error: Error: not found: dustc.
I've manually run the dustc task on the build machine's command prompt every way I know how and it works. I even copied the command from the Bamboo build log - the one it uses to execute the grunt task - and it works just fine.
I just can't get it to work when I run the build from within Bamboo.
Any ideas would be greatly appreciated.
Thanks
This turned out to be a permissions/visibility issue.
Evidently system users (or at least the one which was running my build service) don't have access to the system environment variables in Windows. Learn something new every day!
I created a user to run the service (which I probably should have done in the first place) and that non-system user was able to see the correct PATH settings.
This took care of the problem.
My initial tests have shown that Robot won't work without an active, visible desktop. For example, while a scheduled task (or executed command from the continuous integration server) may be able to start robot as a command-line process, Robot will actually fail to execute the recorded script.
Logging into the build machine to allow it an "active desktop" is not an acceptable solution.
Am I missing something? Is it possible to run a pre-recorded Rational Robot script on a continuous integration server in a manner that doesn't require the machine to be physically logged into?
Unfortunately, Robot does require that you are logged on to the machine and that the desktop is not locked.
So, no, you are not missing something.
Depending on your situation, though, you may be able to work around the issue. Can you clarify what type of application you are trying to test? If it is a web app, or a client app that is easily installed/copied, you might be able to have Robot run on a vmware image, rather than directly on the build server itself.
You can run Rational Robot from the command line, so you should be able to set up a scheduled task to run a .BAT file to do this for you. The command is something like:
[path to Rational Robot]\rtrobo [script file] /user "user name" /project [project file] /play /build "build name" /nolog /close
The Robot documentation will have other arguments you can pass in, depending on your situation.
If a simple scheduled task doesn't work, then you can try setting up a STAF (http://staf.sourceforge.net/index.php) environment and create a job to run this.
Good luck :)