I am adding content previously remove from ProfDFrancis' post which is useful for context of the question:

Update: Summary from answers

There are excellent answers below. The key is to realize that when you write a Cypress test like this:

it("...",()=>{
   callFunctionA()
   b += 1;
   cy.log("Hello from line C")
   d = 10;
   cy.get("#input-box-e")
   console.log("f")
})

... what actually happens is:

   callFunctionA()
   b += 1;
   Add to list to do LATER: cy.log("Hello from line C")
   d = 10;
   Add to list to do LATER: cy.get("#input-box-e")
   console.log("f")

Why? I think it is because Cypress was designed specifically to interact with web pages. The overwhelming priority is therefore to queue up the cy.get() commands, and retry them until they time-out, etc. That is so important that the makers of Cypress are willing (and indeed forced) to subvert our naive expectations of what an apparently synchronous list of code statements mean.

Only by pushing the cy.get commands into a queue where they can be tried and retried, can the web page engagement work so well.

I assume cy.log was added into the set of things that get added to that queue, simply because it is part of cy..

Explanation of the behaviour I saw

I think what was happening in my cases above is that the expect is, effectively, plain Javascript (not a thing dangling off cy.), and so it was executed first, while the cy.log was pushed into a queue to do later.

When the expect was successful, the cy.log eventually printed.

When the expect failed, that aborted the queue of cy. commands for that test, so the cy.log never printed.

Solution

So yes, if we want to log output immediately and not conditionally on the test passing, we should use console.log not cy.log.

Or we can delay the testing to occur inside the cy. queue, using cy.then(), as shown by @Fody.