It's almost as if they are trying to create a mental vendor lock-in to make it more difficult to understand any other test automation framework.
suite setup: beforeAll
suite teardown: afterAll
testcase setup: beforeEach
testcase teardown: afterEach
before each (global scope)
after each (global scope)
before each (global scope)
after each (global scope)
I think module-global would be more accurate. A truly "global" beforeEach would have to fire before every testcase regardless of suite membership (test file).
Practically each module (test file) acts as a top level suite while describe is used to create nested suites.
I remember coming from xUnit frameworks (and languages that don't support closures) made Jasmine's approach to suite/testcase composition seem quite foreign.
But one of the key insights of Domain Driven Design is ubiquitous language - a concept which applies to most communication in general - don't use multiple terms to refer to the same thing, it creates unnecessary friction and ambiguity where there shouldn't be any.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why did they have to use a new term?
Traditionally it has always been identified as a suite.
It's almost as if they are trying to create a mental vendor lock-in to make it more difficult to understand any other test automation framework.
beforeAllafterAllbeforeEachafterEachI think module-global would be more accurate. A truly "global"
beforeEachwould have to fire before every testcase regardless of suite membership (test file).Practically each module (test file) acts as a top level suite while
describeis used to create nested suites.I remember coming from xUnit frameworks (and languages that don't support closures) made Jasmine's approach to suite/testcase composition seem quite foreign.
Not sure why they changed the naming, but for me it doesn't make that much of a difference.
Either name it x or z
I don't doubt it.
But one of the key insights of Domain Driven Design is ubiquitous language - a concept which applies to most communication in general - don't use multiple terms to refer to the same thing, it creates unnecessary friction and ambiguity where there shouldn't be any.