I have a doubt about about whether I should consider a certain type of test functional or contract.
Let's say I have an API like /getToolType, that accepts a {object" "myObject"} as input, and returns at type in the form {type: "[a-z]+"}
It was agreed between client and server that the types returned will match a set of strings, let's say [hammer|knife|screwdriver], so the consumer decided to parse them in an enum, with a fallback value when the returned type is unknown.
Should the consumer include a test case for each type(hammer, knife, screwdriver) to ensure the producer is still following the agreement that it will always return , for instance , the lowercase string "hammer" when /getToolType is called with an hammer object?
Or would you consider such a test case as functional? And why?
IMO the short answer is 'no'.
Contract testing is more interested in structure, if we start boundary testing the API we move into functional test territory, which is best done in the provider code base. You can use a matcher to ensure only one of those three values is returned, this should ensure the Provider build can't return other values.
I would echo #J_A_X's comments - there is no right or wrong answer, just be wary of testing all permutations of input/output data.
Great question. Short answer: there's no right or wrong way, just how you want to do it.
Longer answer:
The point of Pact (and contract testing) is to test specific scenarios and making sure that they match up. You could simply, in your contract, create a regex that allows any string type for those enums, or maybe null, but only if your consumer simply doesn't care about that value. For instance, if the tool type had a brand, I wouldn't care about the brand, just that it's returned back as a string since I just display the brand verbatim on the consumer (front-end).
However, if it was up to me, from what I understand of your scenario, it seems like the tool type is actually pretty important considering the endpoint it's hitting, hence I would probably have specific tests and contracts for each enum to make sure that those particular scenarios on my consumer are valid (I call X with something and I expect Y to have tool type Z).
Both of these solutions are valid, what it comes down to is this: Do you think the specific tool type is important to the consumer? If it is, create contracts specific to it, if not, then just create a generic contract.
Hope that helps.
The proper state is that consumer consumes hammer, knife, and screwdriver, c=(hammer,knife,screwdriver) for short while producer produces hammer, knife, and screwdriver, p=(hammer,knife,screwdriver).
There are four regression scenarios:
c=(hammer,knife,screwdriver,sword), p=(hammer,knife,screwdriver)
c=(hammer,knife,screwdriver), p=(hammer,knife,screwdriver,sword)
c=(hammer,knife,screwdriver), p=(hammer,knife)
c=(hammer,knife), p=(hammer,knife,screwdriver)
1 and 3 break the contract in a very soft way.
In the 1st scenario, the customer declared a new type that is not (yet) supported by the producer.
In the 3rd scenario, the producer stops supporting a type.
The gravity of scenarios may of course wary, as something I consider soft regression, might be in a certain service in a business-critical process.
However, if it is critical then there is a significant motivation to cover it with a dedicated test case.
2nd and 4th scenarios are more severe, in both cases, the consumer may end up in an error, e.g. might be not able to deserialize the data.
Having a test case for each type should detect scenario 3 and 4.
In the 1st scenario, it may trigger the developer to create an extra test case that will fail on the producer site.
However, the test cases are helpless against the 2nd scenario.
So despite the relatively high cost, this strategy does not provide us with full test coverage.
Having one test case with a regex covering all valid types (i.e. hammer|knife|screwdriver) should be a strong trigger for the consumer developer to redesign the test case in 1st and 4th scenario.
Once the regex is adjusted to new consumer capabilities it can detect scenario 4 with probability p=1/3 (i.e. the test will fail if the producer selected screwdriver as sample value).
Even without regex adjustment, it will detect the 3rd scenario with p=1/3.
This strategy is helpless against the 1st and 2nd scenario.
However, on top of the regex, we can do more.
Namely, we can design the producer test case with random data.
Assuming that the type in question is defined as follows:
enum Tool {hammer,knife,screwdriver}
we can render the test data with:
responseBody = Arranger.some(Tool.class);
This piece of code uses test-arranger, but there are other libraries that can do the same as well.
It selects one of the valid enum values.
Each time it can be a different one.
What does it change?
Now we can detect the 2nd scenario and after regex adjustment the 4th one.
So it covers the most severe scenarios.
There is also a drawback to consider.
The producer test is nondeterministic, depending on the drawn value it can either succeed or fail which is considered to be an antipattern.
When some tests sometimes fail despite the tested code being correct, people start to ignore the results of the tests.
Please note that producer test case with random data is not the case, it is in fact the opposite.
It can sometimes succeed despite the tested code is not correct.
It still is far from perfect, but it is an interesting tradeoff as it is the first strategy that managed to address the very severe 2nd scenario.
My recommendation is to use the producer test case with random data supported with a regex on the customer side.
Nonetheless, there is no perfect solution, and you should always consider what is important for your services.
Specifically, if the consumer can safely ignore unknown values, the recommended approach might be not a perfect fit.
This is the 1st time I meet this.
Normally when we received an inbound X12 file. A 999 will always be generated (by configuration in BizTalk) and in case of interchange level error occurs, a TA1 will be created.
But today I got a X12 file with some formatting errors, the error popup in BizTalk is :
Delimiters are not unique, field and component seperator are the same.
The sequence number of the suspended message is 1.
I am expecting to have a 999 or TA1 generated to reject the inbound file. but none of these 2 files created.
My question:
What file shall I expect to created for this kind of error? 999 or
TA1?
Is this a bug or normal behavior for BizTalk?
If this is normal, what is the best mechanism to catch this error and
response back to trading partner.
You should definitely not expect a 999 (which would be transaction set specific), because this error prevents BizTalk from parsing the transaction set at all - it doesn't have a reliable way to determine what kind of transaction it is.
A TA1 could be appropriate, but this seems like a grey area - might be worth contacting Microsoft support about. The documentation indicates that an invalid ISA should result in a negative TA1, but the error codes for TA1 don't list this particular scenario as one that's support (or at all).
A possible work around would be capturing this kind of message, generating a TA1 for it, and routing it back to the TP. However, having non-unique delimiters may make it impossible to determine the TP from the message itself, even though you might be able to determine it from context (but maybe not if multiple trading partners use the same ports/locations). My guess is that's why BizTalk isn't handling it properly out of the box. To be honest, unless this happens fairly frequently it'd probably be easier/more realible to deal with it on an exception basis with human intervention.
As far as capturing the message, I'm thinking you'd need a custom pipeline component - perhaps even subclassing the EdiDisassembler so you can catch this particular exception and deal with it.
I'm an IBM BPM developer and I have following issue:
On my BPD I have an intermediate event that is triggered by a UCA that is called from an Human Service. Everything is working fine, the only problem is that I always get a warning like this in the System.Out.log:
CWLLG0297W: The intermediate event with ID BpdEvent.51155527-fdce-45de-b2be-5da9fb67ab7a can never receive a message from UCA UCA.5e12e401-0968-49f4-8c63-fb7110fdbfb6 because it is correlated on an invalid output parameter.
I tried correlation on tw.system.process.instanceId and tw.system.currentProcessInstance.id, both works, but both rise the warning. Following my researches that's a common issue for BPM 7.5 and 8, but I'm using 8.5.6 and also in 8.5.5 the behaviour is the same.
Can anyone help me?
Thanks in advance!
No, IME stands for "Intermediate Message Event", which is the widget on the BPD that listens for the UCA completion that it will use to correlate. A UCA can't really have a correlation problem, since it does do correlation. A correlation problem is a problem with the listener, a.k.a. the IME. All I'm suggesting is that you pick one of the listeners on the BPD, delete it and recreate it. The test to see if it is now correlating properly. If so, then you fell victim to a copy/paste bug.
from https://www.ibm.com/developerworks/community/forums/html/topic?id=1fd6422f-c361-413f-a5f9-7280557e269d
I have an asterisk server set up as a telephone exchange. I have, on it, a 100 extensions, from 00 - 99. I am running specific functions on each of those extensions. Some of these functions may need the extension on which the call was received to be available. How can I access the same? For example,
Say a call comes in on extension 55.
55 has a function associated with it. That function must take in 55 as an input parameter. How do I do this?
I have tried the following:
exten => 0,n,Verbose(1, "Call on ${EXTEN}-${CHANNEL}")
Output is : Call on 0-DAHDI/20-1
Thanks,
Sriram Shankar.
The answer you are looking for is dependent upon the path that the call is taking through your system. The easiest way to determine the answer to your question is to place the call and then run the following commands from within the Asterisk CLI:
> core show channels
This will show you what channels are active. Find the channel name of your call.
core show channel [channel-name]
This will output an array of channel details, including different variables that are set and their corresponding values. Look for the extension number you are trying to grab in the value fields and then look to see what the corresponding variable name is. It could be ${CALLERID(num)}, ${CALLERID(dnid)}, something under the ${CDR} variable, or even elsewhere.
If you don't find it in the output produced by "core show channel [channel-name]", you may have to trace the dialplan path that the call is taking and try setting the variable early on when the DID information is still available.
So we can use isObservable to work with some systems but I wonder If we can make tham show staps or do something like that. Is that possible?
I'm supposing that you are actually referring to the Observable and Controllable commands which are part of the DynamicSystems package.
Some Maple routines have so-called userinfo messages, which are optionally displayed and which can show partial steps. Those would typically be enabled with a call like infolevel[DynamicSystems]:=6 where 6 is the highest level of detail. With a lower value less detail might be displayed. Unfortunately, these particular DynamicSystems routines don't seem to have any userinfo messages in them. So this won't help directly in your case.
Sometimes one package calls another. The routine LinearAlgebra:-Rank is called, at some point, when Controllable is called. I'm guessing that you don't wish to see userinfo messages in Rank, which would be enabled by issuing infolevel[LinearAlgebra]:=n for some n between 1 and 6.
An alternative is to set printlevel high. But doing so will make all Maple internal calls also be verbose. The resulting output of setting, say, printlevel:=20 is overwhelming. I doubt that you'd find this approach useful.
Another alternative is to set certain routines as option trace. Sometimes doing so entails knowing the names of the appropriate internal routines. And this is made more complicated by the fact that not all non-exported module locals are visible by default. You could try first issuing the call, trace(DynamicSystems::ControllableSS): before invoking Controllable on your system. That shows some intermediary results, but those might not make much sense to you unless you know what source lines are generating those results. You can see the source by issuing the command, showstat(DynamicSystems::ControllableSS);
Here's an example,
restart:
with( DynamicSystems ):
aSys := StateSpace( <<1,2>|<3,4>>, <<2,3>>, <<1,0>|<0,1>>, <<0,0>> ):
aSys:-a, aSys:-b, aSys:-c:
trace(DynamicSystems::ControllableSS):
Controllable( aSys );
showstat(DynamicSystems::ControllableSS);
By looking at the source of the ControllableSS routine, you can deduce that it calls DynamicSystems:-StaircaseTransformation when the staircase method is specified. So here too you could issue showstat(DynamicSystems::StaircaseTransformation) to see the source of that internal (local) routine. Or you could trace that routine as well.
As a general rule, you can refer to exports of a module or package using the :- notation. And you can pass such names to trace and showstat using the :: notation instead of :-, unless you have first set kernelopts(opaquemodules=false). If an inner submodule member has more than one :- in its name then you'd have to use round-bracket delimiters to refer to it with the :: syntax. Sorry, that that's not so easy to express.