I just want to know something about Katalon Studio. I have not worked in automation testing before but now I have some assignment about testing in Katalon.
My client wants to test in Katalon but his requirement is that he wants to run test cases on every build automatically and he also doesn't want to install Katalon IDE or any library he just want reference so that he just added that reference on every build so that all the test cases run automatically on every Dev build.
Is this possible using Katalon? Kindly help me, please. Thanks.
You have to establish full CI Pipeline for your requirements. My advice is, to use Katalon with Jenkins and your developers code repository (perhaps GIT or SVN). Than you are able to implement a server/slave pipeline, where you can execute your Katalon scripts on slave, every time DEV builds.
See:
Katalon/Jenkins Tutorial
I'm tyring to find a better method to run my SBT project with continuous build (compile) and run, SBT can already do continuous compile and test but not with the run command unless I'm not aware how that is possible.
I tried using the ~ command on run but it does nothing
sbt clean compile ~run
I tried using the spray sbt plugin
addSbtPlugin("io.spray" % "sbt-revolver" % "0.9.1")
but it is so tempremental and hangs a lot while trying to kill the current process making it faster to just kill the app then run sbt clean compile run
Is there a way to achieve this?
sbt clean ~run should work fine and rerun main method every time you change the sources. But if you're running a web server which is supposed to run continuously, sbt won't interrupt it to rerun.
So you should use sbt-revolver for that and solve any problems with it by either asking another question or submitting a bug report for the plugin.
I need to run tests, and have them exiting the meteor process with a certain exit code, depending on success/failure. I need to do this inside Meteor.startup.
I tried process.exit(1), but only see on the console:
=> Exited with code: 1
=> Your application is crashing. Waiting for file change.
I need the process to actually exit with the proper exit code (for example, for acknowledging CI about unsuccessful runs).
How can I achieve this?
I don't want to use Velocity, I'm actually trying to come out with a simpler testing approach that suits my needs for a particular project.
meteor --test is a Velocity command that is built-in to Meteor. You may want to use meteor --once so that Meteor does not restart
I've found a way:
Running meteor --test lets you exit from within Meteor with process.exit.
Trying to setup my integration flow and I have some tests that are quite destructive using the velocity-cucumber package.
First issue I find is that these tests are being run on the standard Meteor db. Which on localhost and dev is fine, but not so great for production. As far as I can tell the velocity-cucumber doesn't do anything with mirrors yet.
Because of this I have two cases where I need Meteor to launch in a specific way.
1) On the CI server I need for JUST the tests to run then exit (hopefully with the correct exit code).
2) On the production server I need Meteor to skip all tests and just launch.
Is this currently possible with Meteor command line arguments? I'm contemplating making demeteorize a part of the process, and then use standard node.js testing frameworks.
To run velocity tests and then exit, you can allegedly run meteor with the --test option:
meteor run --test
This isn't working for me, but that's what the documentation says it is supposed to do.
To disable velocity tests, run meteor with the environment variable VELOCITY set to 0. This will skip setting up the mirror, remove the red/green dot, etc.:
VELOCITY=0 meteor run
When using an automated build system, it is usually a source control entry which executes tests (but I assume this can be configured to not be on every entry in a large team). How comes build applications have actions for source code checkins. Is there any need for this? So to summarise, is a build script executed by a source control entry or at a certain time everyday?
Also, the term "break the build" - does this mean code put source control and when the build is executed, it fails due to the code not passing a unit test/code coverage app returns negative results below a certain threshold?
Finally, what does a step mean? (Eg one step build)?
Thanks
So to summarize, is a build script executed by a source control entry or at a certain time everyday?
This depends. Some teams use a commit in the version control system as trigger, some teams use a temporal event as trigger (e.g. each hour). If you run the build after each change, you get immediate feedback. If you let some time run between two builds, you delay that feedback and, in case of a build failure, it's harder to identify the change(s) that are the cause. It may require more investigation.
Just to clarify the vocabulary, for me, "the build" is actually the script/tool that automates all the things that needs to be done (compiling, runing tests, etc). Then running this automated build continuously is what people call "continuous integration". And triggering a build on an event (time based or on commit), pulling the sources from the repository, running the build script, notifying people in case of failure is the responsibility of a "continuous integration engine".
Also, the term "break the build" - does this mean code put source control and when the build is executed, it fails due to the code not passing a unit test/code coverage app returns negative results below a certain threshold?
This is very binary indeed: the build passes, or it doesn't. When it doesn't, there can be many reasons: the code didn't compile, a test failed, a quality check failed (coding standards, code coverage, etc). If you commit some code than causes a build failure (whatever the reason is), then you "broke the build".
Finally, what does a step mean? (Eg one step build)?
In my opinion, a one step build means that you can build your entire application, run the tests, run the quality checks, produce reports, assemble the application, deploy it, etc with one command. This is a synonym of automated build (if you can't run your build in one step, i.e. if it requires human intervention, then it isn't fully automated).
Also, the term "break the build" -
does this mean code put source control
and when the build is executed, it
fails due to the code not passing a
unit test/code coverage app returns
negative results below a certain
threshold?
This could mean different things depending on company, project or team.
Usually "build" is some reference (usually automated) procedure which is either succeeds or not.
Thus "breaking the build" is doing something that leads failing of this reference procedure.
It could include or exclude unit-tests running, or regression test running, or deployment of your product, or whatever your team thinks should never fail.