I just updated my old project to use version 4.13.0 and there was a lot of exception validation with ComparisonMode.Substring, but ComparisonMode.Substring does not exist in the newest version. I found this that explains that:
As a result of this, I decided that as of version 2.1, the ComparisonMode is obsolete and any assertions against the exception message is treated as a case-insensitive wildcard match.
But now I get loads of failed tests with:
Expected exception message to match the equivalent of "Value of
argument 'PeriodEnd' must be greater than '01.01.0001'", but "Value
of argument 'PeriodEnd' must be greater than '01.01.0001'. Value is
'01.01.0001'.
Parameter name: PeriodEnd" does not.
string I assert with
Value of argument 'PeriodEnd' must be greater than '01.01.0001'
The one it expects
Value of argument 'PeriodEnd' must be greater than '01.01.0001'. Value is '01.01.0001'.
Parameter name: PeriodEnd
But from the "patch notes" from before it seems that it should be a wildcard, and the string I assert from is a substring of the one it really is, so why does it fail?
You still need to add the wildcard characters to the call to WithMessage, just like you did when ComparisonMode.Wildcard still existed. The rationale is explained in this post:
If you need to verify that a certain string value or exception message matches the expectation, never verify the exact message. Use wildcards to verify the specific parts that are relevant to verify that the behavior meets the expectation. It will save from unexpectingly failing tests if you decide to refine the text involved.
Related
When I look at the definition of a String type in the FIX protocol (e.g. here or here), I don't see a minimum length specified. Is it allowed to use empty strings? One online decoder seems to accept an empty string value (see tag 320), an other complains that it's invalid.
The FIX 4.4 specification states the following (emphasis in the original text):
Each message is constructed of a stream of <tag>=<value> fields with a
field delimiter between fields in the stream. Tags are of data type
TagNum. All tags must have a value specified. Optional fields without
values should simply not be specified in the FIX message. A Reject
message is the appropriate response to a tag with no value.
That strongly suggests (but does not unambiguously state) to me that the use of an empty value for a string is invalid. It is unsurprising to me that different FIX implementations might treat this edge case in different ways. So, I think the best approach is to avoid using empty values for strings.
+1 for Ciaran's and Grant's answer/comments. Just want to add something.
I generally suggest to look up things like this in the most current specification since they usually have been refined/reworded/clarified to eliminate unclear or ambiguous statements from older specs.
The answer is on the very page you link to in your question (emphasis mine, search for "Well-formed field"): https://www.fixtrading.org/standards/tagvalue-online/#field-syntax
A well-formed field has the form:
tag=value<SOH>
A field shall be considered malformed if any of the following occurs as a result of encoding:
the tag is empty
the tag delimiter is missing
the value is empty
the value contains an <SOH> character and the datatype of the field is not data or XMLdata
the datatype of the field is data and the field is not immediately preceded by its associated Length field.
I use assertJ in my project for nice formulation of test assertions.
I call anySatisfy on a collection where I pass assertions in a lambda that must be met for at least one of the collection elements.
assertThat(myCollection).anySatisfy(myCollectionElement-> {
assertThat(myCollectionElement).callAnyAssertionMethod();
assertThat(myCollectionElement).anotherAssertionMethod();
}
Once no element satisfies the required assertions, anySatisfy fails as expected.
The problem is that the console output then as follows
java.lang.AssertionError:
Expecting any element of:
<allCollectionElementsArSerializedHere>
to satisfy the given assertions requirements but none did.
at myPackage.myTestClass.myTestMethod(MyTestClass.java:xyz)
Concluding I do know that anySatisfy being called in line xyz failed, but I do not get to know which particular assertions inside the lambda are not met. I only can see that in the debugger.
How can I achieve to get the expected log output?
You can't but we have improved allSatisfy to report the unsatisfied requirements.
We will do the same for anySatisfy for the next release, I have created https://github.com/joel-costigliola/assertj-core/issues/1400 to track this.
i am trying to stage a dataset from source to my server, When I run my job in DataStage, It keeps stucked with no errors.
All I see is a warning which says:
When checking operator: When binding output interface field "DRIVERS" to field "DRIVERS": Implicit conversion from source type "dfloat" to result type "sfloat": Possible range/precision limitation.
Try to reset and see if you get any other information......! otherwise one thing straight you can do is use Cast function to convert that to integer and process if the source is a DB, if it is a file read as is and change it in Transformer. hope this helps.
When checking operator: When binding output interface field "DRIVERS" to field "DRIVERS": Implicit conversion from source type "dfloat" to result type "sfloat": Possible range/precision limitation.
You have to learn to read APT/Torrent error messages, which is the company that originally created Datastage PX. It is say:
When checking operator ===> As the compiler is pre-checking a stage
When binding ... "Drivers" ===> I'm looking at a stage in which you are assigning the input field "driver" to the output field "drivers"
Implicit conversion from source type "dfloat" to result type "sfloat": ===> You've got a type mismatch
I believe you can tell datastage to compile even if you get warnings, but the real answer is to go back inside your job and figure out why you're sticking a dfloat (double precision) into an sfloat (single precision). It's likely that you need to specify how to get from dfloat to the sfloat using a transformer and a user specified rule for accuracy truncation.
Under Window > Preferences > General > Search, there is the option Ignore potential matches
What does it do? Whether I activate it or not, I never see a difference.
Is it an option that only makes sense for Java development (which I never do, but I do develop in C, Python and PHP using Eclipse)?
See bug 127442 for examples: depending on what you are searching (a class, a method, ...), the Search engine can find instances which could match (but it cannot say for certain).
Those instances are marked "POTENTIAL_MATCH":
A method with different number of parameters is not a potential match.
(see bug 97322 )
A potential match is a match where the resolution failed (e.g. the method binding is null).
If the user searches for "foo(String)" (without qualifying String), then "foo(java.lang.String)" and "foo(p.String)" are both exact matches.
For the .class file case, I think we can only have potential matches in the case of the missing type case (see bug 196200), i.e if the .class file was compiled and some types it references were missing.
A current example of potential match misbehavior is found in bug 382778:
I have a public static void method printIt(String name).
When I open its call hierarchy, some callers are missing.
I am guessing the callers are missing because java search marks them as potential instead of exact matches for the printIt(String) reference.
The following code is sometimes marked as potential, and sometimes exact:
// Listing 1
PublicInterface2 impl2 = new Impl2("Name Broken");
Static.printIt(impl2.getName());
When the search result is marked potential, the caller is missing from the printIt() call hierarchy.
PublicInterface2 is an empty public interface which extends PackageInterface2Getters.
PackageInterface2Getters is an empty default-scoped interface which extends PackageInterface1Getters.
PackageInterface1Getters is a default-scoped interface which declares String getName().
So impl2.getName() above returns a String.
There are some problems reported which I guess make the matches be marked as potential:
...
Filename : \D:\workspace\eclipse\_runtimes\jdt\call-hierarchy-bug\src\main\PublicInterface2.java
COMPILED type(s)
2 PROBLEM(s) detected
- Pb(2) PackageInterface1Getters cannot be resolved to a type
- Pb(327) The hierarchy of the type PublicInterface2 is inconsistent
Turns out that:
The compiler asks the "NameEnvironment" to get the type information of any dependent type.
Search has it's own NameEnvironment implementation in JavaSearchNameEnvironment and it is not looking for secondary types.
This is bad and it is surprising that we haven't run into this problem until now.
In Eclipse Luna (Service Release 1 (4.4.1)) I searched just for references to this Java method:
merge(DashboardConfigurationModel template, DashboardModel custom)
It returns two references. One of these calls to the merge() method passes in a DashboardConfigurationModel and a DashboardModel, as befits the method signature. This is a match all right!
The other reference to a merge() method passes in a String and a Map. It is marked in Eclipse as a "potential match" but in my mind, since the argument types don't match, this has zero potential to be a match.
I then checked Ignore potential matches, did the search again, and this noise went away.
this throws an exception, when the field does not exist:
reader.IsDbNull(reader.GetOrdinal("FieldName")) => bang
Why not return -1 ?
I'll try to guess here.
The common pattern for this method is to call GetOrdinal for column name and then call GetXXX() methods with given ordinal which is faster than do a search by column's name every time.
Therefore in case of exception here we fail fast and we can't ignore it. Wihtout exception we will try to find a column that doesn't exist and then try to find a field by given ordinal (without checking for -1 which is very easy to omit in this case) and only here we will realise that something went wrong few steps before (may be even too many steps before).