How to call a method from one test case by using Katalon Studio?
For example, I have a test case Purchase order and I have two test methods(test method1 and test method2 in it, Now what I want to do is, I want to create a new test case and call only test method2 in it.
Please suggest
You can simply call an existing test case from a test case with this code:
WebUI.callTestCase(findTestCase({Test Case ID}), [key1:value1, key2:value2, … , keyN:valueN], FailureHandling.option)
A quick example:
WebUI.callTestCase(findTestCase('TestCaseToCall'), [:], FailureHandling.STOP_ON_FAILURE)
If that method2 consist purely of actions on one page, you could implement page object model:
package com.yourEntityName.pages;
import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject;
import com.kms.katalon.core.exception.StepFailedException;
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI;
public class YourPage {
public void method2() throws StepFailedException {
// ...implementation goes here...
}
}
and just call it from the two test cases:
new YourPage().method2();
NOTE: a couple things about this:
this is called a Custom Keyword. More on that here.
there is no logging of any of the steps of this method, so you might want to KeywordUtil.logInfo() the important steps
as corollary to second bullet point, git gud at debugging/troubleshooting, and
make damn sure that whatever code you write here works seamlessly
Related
In my existing [OneTimeSetup] method, I want to check some preconditions before running any test. But I can't do so as the object which I'll be needing to check preconditions is initialized in Base class [Setup] method. I can't initialize this earlier due to some project limitations.
So, Is there any way where I can execute some code after Base [Setup] method (to check some preconditions) and before any suite execution? I want to execute this once per suite.
[SetUpFixture]
Class GlobalSetup
{
[OneTimeSetUp]
public void OneTimeSetUp(){
setup();
CheckIfDataIsPresent(); // I can't do this here as this code needs Obj O to be initialized. which will be initialized in Base class's [Setup] methed
}
}
Public class Base
{
[Setup]
public void setUp()
{
//some code where we initialize obj O;
}
}
[TestFixture]
public class Test : Base
{
// tests to be executed
}
You already did a nice job of explaining why what you want to do won't work, so I don't have to. :-)
The problem is that each your tests needs a fresh instance of that object, so you properly create it in a [SetUp] method. You would like to ensure that it's possible to create such an object once before you run any tests.
I can only give you a non-specific answer, since you haven't given a lot of info in your example code. If you update your question, I may be able to update my answer. Here goes...
Both your tests and the check you want to perform require an instance of object o. So one approach would be to initialize o one more time in the OneTimeSetup, perform the check and then throw it away. Since you are initializing o in every test, I assume it's not expensive to do so. Say you have 100 tests. You are setting up o 100 times. So make it 101 and be done!
Alternatively, determine what is required for o to be initialized successfully and check that. For example, if it needs a file to be present, check that the file is present. If the file has to have 100 records in some format, check that it's so. Perhaps you might give us more detail about what those prerequisites are.
Finally, you might reconsider whether you really need a new instance per test. Since you suggest you would be willing to make a check once per fixture (I assume that's what you mean by suite) then perhaps you really only need one instance per fixture rather than a new one for each test.
I am new to Nunit and Moq
I have a static class like this:
public static class StaticClass1
{
public static void Prepare()
{
//some logic
}
}
public static class StaticClass2
{
public static void Initialize(some_parameter)
{
//some logic
if (some_condition(some_parameter))
{
StaticClass1.Prepare();
}
}
}
I need to test the function AccountService.Initialize() in which I need to verify StaticClass1.Prepare() is being called at least once
I think that to answer this question I would say something like "You need to get experience in how to layer a project".
When unit testing a method you want to unit test that single method, and mock the dependencies, exactly as you try to do if I understand you correctly. Now it's not optimal to call static public methods from one class to another static method in another class since it makes it difficult to isolate you unit tests and what they should test (you end up with testing two completely different methods in the same unit test instead of separating the code and unit tests).
On another approach you break the D in SOLID (Dependency inversion principle) that you can read more about here -> https://en.wikipedia.org/wiki/SOLID_(object-oriented_design). You want to depend upon abstractions rather than concrete classes.
Lastly I thought that I would be a bit selfish and share a link to an article series that I have written myself. It's about Test Driven Development and uses Moq as unit testing tool and focuses on how to think when layering and unit testing a complete project (in a small scale). I'm absolute certain that it will help you understand on how to continue with you own projects and code.
It's based upon 4 articles. The first in the series is here -> http://www.andreasjohansson.eu/technical-blog/getting-started-unit-testing-a-web-project-part-1-introduction-and-setting-up-the-project/
Hope it helps!
I have an old version API: Foo(). Now I extend the API to Foo(false), Foo(true) and Foo() should still work as before.
Right now I am using Parameterized.class to do Junit, and the parameter list is {null, false, true}. I want to write the testcase as:
#Test
public void fooTest() {
Foo(parameter);
}
But Foo(parameter) cannot test Foo(), so I have to write the test code as:
#Test
public void fooTest() {
if (parameter == null)
Foo();
else
Foo(parameter);
}
Is there any simple way to write the test case so that I do not need to check whether parameter is null or not? I ask this because the original test cases before I extend API are already there in many places (see below) and I do not want to change the test code too much. :
#Test
public void fooTest() {
Foo();
}
One way could be to put the Foo-Object (instead of the constructor arguments) into the parameters, i.e. {Foo(false), Foo(true),Foo()} instead of {null, false, true}
Yet review your example. Probably it is an abstraction of a real problem. If not:
assertions are missing, these should be contained in the parameters (otherwise you get the if-problem in the assertion phase).
testing with 3 parameter values is easier done with 3 simple (un-parameterized) unittests
And you could of course put your default constructor into a separate (un-parametereized) test class.
Which alternative is the best depends heavily on the real problem behind your abstraction.
I have a companion object with a private method, like so:
package com.example.people
class Person(val age: Int)
object Person {
private def transform(p: Person): Person = new Person(p.age + 1)
}
I would like to test this method, with something like:
class PersonSpec extends FlatSpec {
"A Person" should "transform correctly" in {
val p1 = new Person(1)
val p2 = Person.transform(p1) // doesn't compile, because transform is private!
assert( p2 === new Person(2) )
}
}
Any help on having test code access private methods?
Actually, as it is written, I might be able to create a subclass of Person, but what if Person is declared as final or sealed?
Thanks!
I am in the middle when it comes to testing everything. I don't usually test everything, but sometimes it's really useful to be able to unit test a private function without having to mangle my code to make it possible. If you're using ScalaTest, you can use the PrivateMethodTester to do it.
import org.scalatest.{ FlatSpec, PrivateMethodTester }
class PersonSpec extends FlatSpec with PrivateMethodTester {
"A Person" should "transform correctly" in {
val p1 = new Person(1)
val transform = PrivateMethod[Person]('transform)
// We need to prepend the object before invokePrivate to ensure
// the compiler can find the method with reflection
assert(p2 === p1 invokePrivate transform(p1))
}
}
That may not be exactly what you want to do, but you get the idea.
You could declare your method to be package private:
private[people] def transform(p: Person): Person = new Person(p.age + 1)
If you put PersonSpec in the same package it will be able to access it.
I leave it to you to decide if it's really wise to unit test a private method :)
The need to unit-test private methods is a design smell.
Either you test them through your public API which is ok if they are small and just helper methods - or, which is more likely, it contains different logic/responsibility and should be moved to another class that is used by delegation in the Person. Then you would test the public API of that class first.
See a related answer for more details.
Likely you can access it using Java/Scala reflection, but it is just a workaround for the design problem. Still, if you need to, see a related Java answer how to do that.
#jlegler's answer here helped me, but I still had some debugging to do before things worked, so I thought I'd write exactly what's needed for this here.
to test:
class A
object A {
private def foo(c: C): B = {...}
}
use:
val theFuncion = PrivateMethod[B]('foo)
val result = A invokePrivate theFunction(c)
Note the locations of A, B
Personally, I say make everything public and just prepend with _ or __ to indicate that other devs shouldn't use it.
I realize this is Scala and not Python, but regardless, "We're all consenting adults here."
"Private" methods aren't actually private (for example) and certainly aren't secure, so why make life harder for what is essentially a social contract? Prepend and be done -- if another dev wants to go poking around in dark places, they either have a good reason or deserve what they get.
Generally speaking: if you want to effectively test your code, you first have to write it testable.
Scala implements the functional paradigm and extensively uses immutable objects by design, "case classes" are examples (my opinion: the Person class should be a case class).
Implementing the private methods make sense if objects has mutable state, in this case you might want to protect the state of the objects. But if objects are immutable, why implement methods as private? In your example, the method produces a copy of Person, for what reason do you want to make it private? I do not see any reason.
I suggest you think about this. Again, if you want to effectively test your code you have to write it testable.
a possible work around would be testing private method indirectly: testing a public method which calls the private method
I don't think that unit testing is about testing contract of the class - it is about testing simple functionality(unit).
Also I don't think that it is a good idea to make some methods public only to make them easily testable. I believe that keeping API as narrow as possible is a good way to help other developers to use your code(IDE will not suggest private methods) and understand contract.
Also we should not put everything in a single method. So sometimes we can put some logic into a private method.... and of course we want to test it as well. Testing it through the public API will increase complexity of you test.(other option is to move logic of the private method to another helper class and test it there..this class will not be used directly by developers and will not clutter up api)
Guys from scalatest ,I think, added PrivateMethodTester for a purpose.
Using Eclipse (Helios), I could create a JUnit test file ClassATest.java of the source file ClassA.java by using New -> JUnit Test Case -> Class under test..., then choose all the methods of ClassA to be tested.
If later we add some more methods to ClassA, how do we easily reflect this addition in ClassATest ? (No copy/paste plz).
One solution is to use MoreUnit
With MoreUnit installed to Eclipse, one can right click onto the newly added method (and not yet unit tested), and choose "Generate Test"
Of course, if one always follows the writing-test-before-writing-method style, then this solution is not needed. However in reality sometimes you don't have a clear idea of what you would want to do, in that case you would have to code up some method, play with it, then rethink and code again until you are satisfied with the code and want to make it stable by adding unit test.
You should look into creating a JUnit test suite which will execute all tests within the classes you specify. Thus, adding new test cases is as simple as creating a new class and adding it to the #Suite.SuiteClasses list (as seen below).
Here's an example.
Example JUnit Test Suite Class:
#RunWith(Suite.class)
#Suite.SuiteClasses({
TestClassFoo.class
})
public class ExampleTestSuite {}
Example Test Case class:
public class TestClassFoo {
#Test
public void testFirstTestCase() {
// code up test case
}
}