I would like to start using an testing framework that does the following:
contains an process(the process can be a test) management engine. It is able to start processes(tests) with the help of a scheduler
it is distributed, processes can run locally or on other machines
tests can be anything:
simple telnet on a given port (infrastructure testing)
a disk I/O or mysql benckmark
a jar exported from Selenium that does acceptance testing
will need to know if the test passed or not
has the capability to get real time data from the test(something like graphite) -- this is optional
allows processes to be build in many programing languages: perl, ruby, C, bash
has a graphical interface
open-source
written in any language as long as it doesn't use resources , I would prefer C, perl or ruby
to run on linux
What not to be:
an add on to a browser: Selenium, BITE ..
I do not want something focused on web development
I will like to use such a tool or maybe collaborate on building one. I hope I was explicit enough. Thank you .
You might want to look at the robot framework combined with jenkins. Robotframework is a tool written in python for doing keyword-based acceptance testing. Jenkins is a continuous integration tool which allows you to schedule jobs, and distribute jobs amongst a grid of nodes.
Robotframework tests can do anything python can do, plus a whole lot more. It has a remote interface, which means you can write test keywords in just about any language. For example, I had a job where we had keywords written in Java. In another job we used robotframework with .NET-based keywords. This can be accomplished via a remote interface (so you can write keywords in many different languages) or you can run robot using jython to run on the JVM, or iron python to run in a .NET environment.
Related
I am one of the developers of a console two-pane file manager for Linux (this is a port of Far Manager, called far2l), the application interface resembles Midnight Commander. I am faced with the need to implement automated testing. Can you please tell me which application or framework can be used for this?
I need the ability to write some scripts containing a sequence of keystrokes that will be transmitted to the console application (the ability to specify delays between emulated keystrokes also needed), as well as the ability to automatically analyze application interface drawn in the console, for example, for the presence of certain strings. And some kind of a framework to run a number of such tests automatically and generate testing reports.
Most console application testing tools I could find (like "cram", "cli-unit", "aruba", or "exactly") unfortunately don't seem to be designed specifically for testing interactive applications.
In what environment should I write the code for the telegram bot so that it works even when the console is not running?
I tried to write code in an online environment, but when I turn it off, the bot does not work.
This depend from the OS you are using (es. Windows, Ubuntu 18.04 etc.), and also from which programming language and which version of it you are using (es. "python 3.6").
If you want to have the code always available to be executed, you need to put the script or the scripts in a server (a dedicated computer) always turned on,you can rent one online or you can do it and set up one by yourself , but this need some knowledge before, and depends on which kind of things you want from your server.
If you're still in the early stage of the bot-development i suggest you to use your localhost or local environment in general to test your work, in this way you can focus to one thing at time , useful especially in your first experiences in developing and coding. If it's not strictly necessary i would focus at one thing at time to learn better step by step.
A lot of programs you download can be run in a blocking manner or in the background (usually by start/stop/etc commands). Some good examples are HA Proxy and Spring Boot apps built to be Linux services... both can be run in either manner.
In system-d unit files you can use "forked" type to allow you to map to start/stop/etc commands for managing a program that runs in the background/as a daemon. Alternatively, you can just use the "simple" type and call the app itself in a blocking manner.
Is there any particular reason to prefer "forked" where it is an option? Having done both options on numerous things, it seems "simple" is lighter on config and more obvious in terms of usage.
This is answered in https://www.freedesktop.org/software/systemd/man/daemon.html section "sysv daemons" there are mostly only downsides of choosing the "forking" method, because most software out there, DO NOT perform the "15 steps" either correctly or at all, in particular, steps 12 and 14 are seldom correctly implemented.
I am trying to automate the creation of JMeter scripts based on existing Cucumber tests to avoid maintaining two separate sets of tests (one for acceptance and one for load testing).
The Cucumber recording works great locally when I add the HTTP Recorder to the Workbench and start the recording, however I cannot figure out how I can automatically start it from the command line. Is this possible at all?
Why not run Cucumber from JMeter?
Because I'd like to avoid running multiple instances of Cucumber at the same time, and I'd like to be able to distribute the load generation (using jmeter-server)
This is not possible yet.
You should discuss this on user mailing list to give more details on your request.
If this looks useful, then you would create an Enhancement request on JMeter bugzilla and feature may be developed.
I use Seapine's TestTrack Test Case Manager (TCM) under Linux and thus far have been unable to figure out how to use its ability to kick off our Perl test scripts and save the resulting data into a test run. Could someone provide me with a config, or example?
Sean,
Take a look at the Script Agent mechanism on our Labs site. That will allow you to kick-off the Perl scripts.
If you have any questions about that, or want some help shoot me an email (mharp#) and we can talk.