Inside Fitnesse DoFixture, you can use check keyword to compare one of the objects with an expected value. I was wondering if there is a check not equal that exists to make sure the expected and actual do not match up.
I have tried using that set of keywords but it is not supported. There is a reject keyword for DoFixtures, but it does not accomplish the goal. Anyone know of a method? For a testing framework, it seems like it should be obvious, but I've had a rough time digging through the UserGuide.
Example:
|check not equal| guid | c1acff01-e45b-4b7d-b6f5-84f8830ef6b4 |
Scenario Pass: guid != c1acff01-e45b-4b7d-b6f5-84f8830ef6b4
I was unable to find this type of test condition, so instead, I put the logic inside the Fixture code with the expectation to return true when a != b. In the Fit code, I had the following:
|check|guidsNotEqual|true|
With fitSharp you can have
|check|mymethod|fail[myvalue]|
This will pass if mymethod is not equal to myvalue. I don't think this works with the Java FitLibrary.
There is an option (might be added after the question was asked). It is possible to check for something not equal by using 'check not'.
So
|check not|this is true|false|
will return true
Related
tl;dr;
Why using
string myVariable = "someInitialValueDifferentThanUserValue99999999999";
as default value is wrong?
explanation of situation:
I had a discussion with a colleague at my workplace.
He proposed to use some trash value as default in order to differentiate it from user value.
An easy example it would be like this:
string myVariable = "someInitialValueDifferentThanUserValue99999999999";
...
if(myVariable == "someInitialValueDifferentThanUserValue99999999999")
{
...
}
This is quite obvious and intuitive for me that this is wrong.
But I could not give a nice argument for this, beyond that:
this is not professional.
there is a slight chance that someone would input the same value.
Once I read that if you have such a situation your architecture or programming habits are wrong.
edit:
Thank you for the answers. I found a solution that satisfied me, so I share with the others:
It is good to make a bool guard value that indicates if the initialization of a specific object has been accomplished.
And based on this private bool variable I can deduce if I play with a string that is default empty value "" from my mechanism (that is during initialization) or empty value from the user.
For me, this is a more elegant way.
Optional
Optional can be used.
Returns an empty Optional instance. No value is present for this Optional.
API Note:
Though it may be tempting to do so, avoid testing if an object is empty by comparing with == against instances returned by Option.empty(). There is no guarantee that it is a singleton. Instead, use isPresent().
Ref: Optional
Custom escape sequence shared by server and client
Define default value
When the user enter's the default value, escape the user value
Use a marker character
Always define the first character as the marker character
Take decision based on this character and strip this character for any actual comparison
Define clear boundaries for the check as propagating this character across multiple abstractions can lead to code maintenance issues.
Small elaboration on "It's not professional":
It's often a bad idea, because
it wastes memory when not a constant (at least in Java - of course, unless you're working with very limited space that's negligible).
Even as constant it may introduce ambiguity once you have more classes, packages or projects ("Was it NO_INPUT, INPUT_NOT_PROVIDED, INPUT_NONE?")
usually it's a sign that there will be no standardized scope-bound Defined_Marker_Character in the Project Documentation like suggested in the other answers
it introduces ambiguity for how to deal with deciding if an input has been provided or not
In the end you will either have a lot of varying NO_INPUT constants in different classes or end up with a self-made SthUtility class that defines one constant SthUtility.NO_INPUT and a static method boolean SthUtility.isInputEmpty(...) that compares a given input against that constant, which basically is reinventing Optional. And you will be copy-pasting that one class into every of your projects.
There is really no need as you can do the following as of Java 11 which was four releases ago.
String value = "";
// true only if length == 0
if (value.isEmpty()) {
System.out.println("Value is empty");
}
String value = " ";
// true if empty or contains only white space
if (value.isBlank()) {
System.out.println("Value is blank");
}
And I prefer to limit uses of such strings that can be searched in the class file that might possibly lead to exploitation of the code.
I need to compare these 2 codes for CPU and RAM usage. who is better?
enableValidation is a Boolean variable and need to set false.
I have 2 ways:
1. use if
2. set false direct
which one is better?
way 1:
if (enableValidation) {
enableValidation = false;
}
way 2:
enableValidation = false;
As far as CPU/RAM usage, there is almost no difference between these two mentioned code approaches. While approach one is checking for a redundant condition. Both code means at this point enableValidation has to be false, no matter what is the situation.
So code readability perspective, better to assign it to false directly.
java and kotlin will be translated to byte codes so you can view byte code and detect wich one is larger code than other
as i know from c++ , the way 2 is better but here the resource usage is about nothing !
dont realy care about it
In my code, I have to assert one value against 2 fields. This is what I have to do :
assertThat(request.get(0).name()).isEqualTo("ABC");
assertThat(request.get(0).name2()).isEqualTo("ABC");
How can I use one single line assertion for the above 2 lines?
For example to explain more what I need :
Is there a way I can achieve something like :
assertThat(request.get(0).name() && request.get(0).name2()).isEqualTo("ABC");
How can I use one single line assertion for the above 2 lines?
Why do you want to do such a thing ?
By trying to try too clever, you will get two drawbacks :
you will make your test more complex to read and to maintain.
you will lose the relevant feedback information as a test fails
Actually your test is fine.
If any of these two values doesn't respect the assertion, you have the exact line that spots the issue and you also have a relevant information message.
As a hint, you could maybe just remove the duplication :
final String expected = "ABC";
assertThat(request.get(0).name()).isEqualTo(expected);
assertThat(request.get(0).name2()).isEqualTo(expected);
I don't want to say that it is bad to make multiple assertions in a same statement. Not at all.
I say only that you have to adapt your way of asserting to the tools you are using.
And about it, you don't specify the matcher tool.
If the matcher tool provides a support to make this kind of assertion, use it.
Otherwise, don't make it in a raw way otherwise you will lose the benefit of getting useful failure test messages.
Here is an example with AssertJ that provides this feature out of box.
#Test
void namesEquals() {
List<Request> requests = new ArrayList<>();
requests.add(new Request("ABC", "ABD"));
Assertions.assertThat(requests.get(0)).extracting(Request::name, Request::name2)
.containsExactly("ABC", "ABC");
}
And in this failing test, you will get a useful information message :
java.lang.AssertionError:
Expecting:
<["ABC", "ABD"]>
to contain exactly (and in same order):
<["ABC", "ABC"]>
but some elements were not found:
<[]>
and others were not expected:
<["ABD"]>
A bit too clever perhaps, but you can try this:
assertTrue(Stream.of(request.get(0).name(), request.get(0).name2())
.allMatch("ABC"::equals));
Or you can give this a spin:
assertThat(Arrays.asList(request.get(0).name(), request.get(0).name2()),
Every.everyItem(IsEqual.equalTo("ABC")));
something like:
assertThat(request.get(0).name().equals( request.get(0).name2()) ?
request.get(0).name() : "false").isEqualTo("ABC");
The first xpath is working whereas the second not:
First:
"//*[#id='j_idt46:j_username']";
Second:
"//*[contains(#id,'username']";
Why?
To what could be figured out of the information provided, the way you are using contains is possibly inappropriate :
As mentioned by #TuringTux - //*[contains(#id,'username')] could be the possible change if the same lined goes as it is in your code.
Also a good practice to follow in //*[contains(#id,'username')] , would be to replace * by an element type in html.
And lastly there could be chances when you are trying to access elements using //*[contains(#id,'username')], you may be ending up getting a list of these similar WebElements while you might be trying to access only a single at the same time.
I am a new bee to Automation and Java. I am working on a problem which requires me to read the read time stock market data from the database and verify it with the same with the value seen on the UI. I am ok having approximations up to 5% in the value. To verify if these tests have passed its important for me to assert the values with the value in the UI.
I have a small logic to verify these values, I wanted to know if this is a good way of coding on java or do i have a better way to achieve these results.
Alorigthm.
I read the int/float value from db.
Calculate 5% of the value in step 1.
Get the value in the UI and assert if its greater then or equal to value in step 2.
If greater i say Asseert.assertEquals(true,true) else i fail my assert.
If any better way to work for these values, request a better answer.
It's more usual to have your Assertion represent the meaning of your test, having to assert(true, true) does not do this. So:
3. Calculate the absoluete difference between the value obtained in step 1 and the UI value (when I say absolute value, you need to remember that the UI might be higher or lower than the db value, you need to make the difference to be always positive)
4. Assert.assertThat( difference < theFivePercentValue)
Also you could consider using the Hamcrest extension to JUnit that includes a closeTo() method.