For content, if your response assertion contains: text1 text3 text2 on a different line each of the strings, but the placement of this strings in the content is text1...text2...text3, then the assertion will fail. Their order matters. If they're in different elements it won't matter. If your app changes layout often, this brakes functional assertions inevitably. I thought this might apply to header assertion also.
On Mon, Mar 11, 2013 at 7:48 PM, sebb <[email protected]> wrote: > On 11 March 2013 17:07, Adrian Speteanu <[email protected]> wrote: > > Hi, > > > > I choose maintainability in these cases. Whatever is easier to you to > > update and maintain is good enough. > > > > In the case of response headers, I'd keep different elements for each > > assertion, because I have no clue whether they will always be returned in > > the order that I have entered them in the assertion, when writing the > test > > script. > > Huh? > > The Response Assertion checks all its pattern entries. > The order does not matter. > > > Cheers, > > Adrian Sp > > > > On Mon, Mar 11, 2013 at 5:33 PM, Jakob van Bethlehem < > [email protected]>wrote: > > > >> Dear users, > >> > >> Currently I'm working on building some header assertions (using Response > >> Assertion) on HTTP Requests. There is a set of 6 headers that our > >> application must send, which I'd like to add to the Response Assertion, > and > >> I was wondering what is the preferred method to achieve this in JMeter: > >> (1) create a single, huge pattern that has all headers (this can be > done, > >> because all 6 headers will come out in a given order), or > >> (2) create a separate pattern for each header > >> > >> I don't know for sure whether the order in which headers are received > >> could ever be mixed up (maybe when the server is stressed?). If that is > the > >> case, I guess method (2) would be preferable. If that is not the case, > >> method (1) would result in a single test to run, which may be faster > than > >> method (2), although it is a huge test. I'm lacking experience here - > >> hopefully someone can give some pointers. > >> > >> Sincerely, > >> Jakob van Bethlehem > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
