Is there a standard way to test scripts / executables in Jenkins?

We have a project that contains a library of Python and Scala packages, as well as Bourne, Python and Perl executable scripts. Although the library has good testing coverage, we have no scripting tests.

The current testing environment uses Jenkins, Python, virtualenv, nose, Scala and sbt.

Is there a standard / common way to enable scripting testing in Jenkins?


Edit: I'm hoping for something simple, like a Python unittest for shell scripting, like:

assertEquals expected.txt commandline
assertError commandline --bogus
assertStatus 11 commandline baddata.in

      

+3


source to share


3 answers


I don't know how "standard" it is, but if you really practice TDD, your scripts should also be developed with TDD. How you connect your TDD tests with Jenkins then depends on the TDD framework being used: you can generate JUnit reports, for example, which Jenkins can read, or your tests can simply return a failure status, etc.



+1


source


You looked at shunit2: http://code.google.com/p/shunit2/

It allows you to write shell test scripts in Bourne, bash or ksh scripts.



Not sure how you can integrate it into what you describe, but it generates output similar to other unit test suites.

+4


source


If your script requires a different project, then my inclination is to create a new jenkins project like "system-qa".

This will be a downstream python project and will depend on the python project and the inner project.

If you have used dependency resolution / publish technology say apache ivy http: // ant.apache. org / ivy /, and if those existing projects were to publish a packaged version of their code (as .tar.gz was possible, maybe) then the system-qa project could declare dependencies (again using ivy) for both python package and your own project package, download it with ivy, extract / install, run tests and exit.

So the system-qa project script build is responsible for fetching dependencies, executing tests against those dependencies, and then possibly posting a standardized format for output tests like junit xml (but with a minimum return of 0 or non-0, to point out Jenkins about how it was built).

I think this is a technically correct solution, but also a lot of work. A subpoena is required if it's worth it.

0


source







All Articles