-
Notifications
You must be signed in to change notification settings - Fork 58
Added beforeAll, beforeEach, afterEach, afterAll lifecycle hooks for testing #57
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple minor things I noticed
lib/TestRunner.lua
Outdated
errorMessage = nodeResult | ||
for _, hook in pairs(lifecycleHooks:getAfterEachHooks()) do | ||
if success then | ||
success, errorMessage = runCallback(hook, true, "after each hook: ") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message prefix here is inconsistent with the prefix for the other lifecycle hooks:
success, errorMessage = runCallback(hook, true, "after each hook: ") | |
success, errorMessage = runCallback(hook, true, "afterEach hook: ") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just took a cursory glance for my evening reading, I'll dive in more at work tomorrow. 😄
Can you revert the changes to files that are just trailing line endings at the end of files? We can go back through the codebase at a later time to catch those and do some other reformatting work.
.gitignore
Outdated
/site | ||
/lua_install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you running hererocks locally? This is an acceptable change, it's just interesting that this is how you got your Lua install to work 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was carry over from the previous pull request. I can remove it if needed.
.luacheckrc
Outdated
}, | ||
} | ||
|
||
std = "lua51+roblox+testez" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we're testing TestEZ itself, we don't generally have access to TestEZ, so I'm not sure that adding it to our Luacheck config is correct here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I dont add it here, Tests/lifecycleHooks.lua wont pass luacheck since we are testing these globals
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should narrow down the scope of what files we inject these globals into, then. I don't want to make Luacheck think that the entire TestEZ codebase has access to these values, it mostly doesn't.
We've got two options I think:
- Use Luacheck assertions on the functions that use these methods, if there's a small number of them.
- Only apply the testez std for the tests folder or even the specific test that depends on these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- seems to be the most applicable, since this sounds like a problem of scoping.
We can create a new luacheckrc file for the tests directory that has the testez std. Would that work?
Edit: We could do 1. as well, there's about 4 tests in lifecycleHooks that use these functions at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to make a new luacheckrc file, just scope the rules using globs to only affect the files in the tests folder like we do in Roact:
https://github.com/Roblox/roact/blob/master/.luacheckrc
Thanks for the first round of feedback. All of it should be addressed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took a more detailed look through this.
[TestEnum.NodeType.AfterAll] = self:_getAfterAllHooksUncalledAtCurrentLevel(planNode.children), | ||
[TestEnum.NodeType.BeforeEach] = self:_getHooksOfType(planNode.children, TestEnum.NodeType.BeforeEach), | ||
[TestEnum.NodeType.AfterEach] = self:_getHooksOfType(planNode.children, TestEnum.NodeType.AfterEach), | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a mouthful!
lib/TestRunner.lua
Outdated
for _, hook in pairs(lifecycleHooks:getPendingBeforeHooks()) do | ||
if success then | ||
success, errorMessage = runCallback(hook, false, "beforeAll hook: ") | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't run afterAll
hooks in this block, but we run beforeAll
here.
Why don't we process beforeAll
above, before we enter this child loop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do that, but if the beforeAll node fails I'm afraid I wont have access to the child nodes it was wrapping as easily
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also if we move beforeAll out, we wont be able to filter out describe blocks with beforeAlls with no It blocks very easily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have the same problem with afterAll
not being filtered? I wonder if we should try to patch this up a little in TestEZ and then start fresh in the new test framework with lifecycle events in mind from the start.
@@ -110,7 +144,7 @@ function TestRunner.runPlanNode(session, planNode, tryStack, noXpcall) | |||
end | |||
elseif childPlanNode.type == TestEnum.NodeType.Describe or childPlanNode.type == TestEnum.NodeType.Try then | |||
if childPlanNode.type == TestEnum.NodeType.Try then tryStack:push({isOk = true, failedNode = nil}) end | |||
TestRunner.runPlanNode(session, childPlanNode, tryStack, childPlanNode.HACK_NO_XPCALL) | |||
TestRunner.runPlanNode(session, childPlanNode, tryStack, lifecycleHooks, childPlanNode.HACK_NO_XPCALL) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function's starting to get a lot of arguments. We're right at the threshold where refactoring it to take a table of arguments might be a good idea, but we can leave that out of this PR.
|
||
local results = TestEZ.TestRunner.runPlan(plan) | ||
return results, lifecycleOrder | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a neat way to test this feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LEt's merge to master!
The setup and teardown behavior of these hooks attempt to reach feature parity with jest.
Test nodes will be marked as failures if the
beforeEach
,beforeAll
, orafterEach
hook throws. Currently there is a limitation in this changelist that does not mark the nodes as failures ifafterAll
hook throws.This pull request replaces the need for #39