Tag Info

Hot answers tagged

6

There are several ways you can work with this situation. No-work - let the tests for the new feature fail until the feature is migrated to the staging environments. This can be an option if the tests don't block builds or aren't reporting directly to management. "smart" detection - as Dale suggested, use some coding to detect whether the feature is ...


3

As always, it depends. If there are regulatory requirements, results need to be kept for as long as the regulations state. Otherwise, it's a business decision. 1. How long does your team keep test results? In my experience this depends on a number of factors. I've been in places where test results for new development would be kept indefinitely, but test ...


3

Resolved this by using JMeter's Duration Assertion as a child to the HTTP Request I wanted to time setting the Duration to Assert in milliseconds to the longest time allowable and Appy to as Main sample only. When this time is exceded the assert fails and the test gets marked as failed.


3

Use JUnit to handle the running of the tests from the Jenkins server. Use JDBC to query the DB for new rows. Change up the Tomcat servers so they send logging events back to the Jenkins serverJUnit test. You'll need to write a little socket listener for the JUnit test to gather the Tomcat events (Writing an LoggingEvent listener isn't hard. I'm not ...


2

The Selenium IRC channel provided a hint. The browser was starting to launch, but Selenium never got a reply. After some fiddling, I was able to remote desktop into the account selenium + tomcat ran as and manually launched a grid job. Chrome was trying to setup a second desktop shortcut and do some initial first launch housecleaning. I also had to relax ...


2

Despite the fact the question is about Jenkins results - I'll add my own 5 cents, but regarding results of manual testing - some of the following points may be as well useful: As stated in other answers, results of intermediate builds are valuable within several months OR current project stage, therefore our usual practice is to keep these within current ...


1

You might be able to do something by swapping out the login shell from /bin/sh to /usr/local/someLoginCheck script so that when users use the ssh remote it checks the job name or some other environment variable set in the job. For example, at the top of the users script: #!/usr/local/someLoginCheck a650ef01ddcf4e1bfb68ee0af5566170 Another option would be ...


1

You should be able to configure a job to watch the app repository and trigger a run when the app repository changes. It will be easier to configure if the company's application is managed through the same Jenkins server as your testing suite (depending on your source control system one Jenkins server can handle multiple source control repositories), but ...


1

The real answer is that you need to keep test results for as long as they are useful. Storage is cheap, so don't let that be the driver behind how long you keep any test artifact. But determining how long results can be of use depends on a lot of company and project-specific conditions. We tend to keep functional results only for the duration of the ...


1

I feel like this is a polling question rather than a SE-type question, but if not.... 1) We keep them for two weeks at my current role, but at other companies several years. 2) Rarely have I needed something more than a couple of days really as I run daily automation tests, but I have found it useful a couple of times when a test has been failing for ages, ...


1

Figured it out. The host IP in the VM configuration window in Jenkins has to be the IPv4 address of the host-only adapter (in this case, 192.168.120.1). I also changed the host port in the port forwarding rule from 3022 to 22. For historical reference, the username and password fields (which appear when the "Advanced" button under the "Host" field in the ...


1

This is a known bug, documented here. It appears you can get around the issue (at least enough to get back into the GUI to revert the change) by deleting the $JENKINS_HOME/plugins/maven-plugin.jpi.pinned file. Standard rules about backing things up still apply.


1

It doesn't look like the Android/Android Emulator plugin for Jenkins has that feature or something similar, You could try using the Jenkins VirtualBox Plugin or VBoxTool get the instance running and set up your tests to execute from there More info on how to configure the VirtualBox Plugin can be found in another question What is the correct way to ...


1

You can fork test tasks from your build tool, whatever it is. With Maven, its called "surefire plugin", with Gradle, you just set "maxParallelTasks" in your test task, with TestNG, you use the thread count like @Aruna suggested. It all depends on what you are using to execute your tests. When selenium tests are forked, then multiple sessions are opened ...


1

In TestNG.xml file there is an attribute "parallel" that could be used to configure running several test methods/classes at the same time in parallel <suite name="mySuite" parallel="methods" thread-count="5"> <suite name="mySuite" parallel="tests" thread-count="5"> <suite name="mysuite" parallel="classes" thread-count="5"> <suite ...


1

If you are using Ruby, I believe you should be able to use green threads to avoid fork() http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html While technically not true parallelism, it should work fine if you are just firing off Watir-Webdriver tests. The idea is to start each thread up separately and have each thread run a test script.



Only top voted, non community-wiki answers of a minimum length are eligible