Achieve 100% test coverage #168
Milestone
Comments
|
@pdf FYI I haven't finished yet but I do have a quite extensive change to move us over to a nicer test suite that is more data-driven and just produces a list of expected vs. gotten DOM operations & will make it much easier to test correct behavior in Vecty without writing crazy verbose DOM mocking code. Just wanted to let you know so you don't do anything too extensive in the test suite any time soon :) |
|
Actually I had some spare hours, so I moved the entire test suite over and sent #178 :) Still todo here is adding more tests to achieve 100% coverage, but it should be a lot easier once that PR is merged. |
slimsag
added a commit
that referenced
this issue
Dec 1, 2019
This PR adds support for rendering into arbitrary DOM nodes in the same way that rendering into the `body` worked previously, with one exception: blocking. `RenderBody` remains blocking, since it effectively becomes a helper that 90% of Vecty applications will rely on, whereas `RenderInto` and `RenderIntoNode` which are introduced in this PR do not block. This is because: a. Anyone rendering Vecty into arbitrary DOM nodes will likely want to do it more than once, so making the API of these functions non-blocking makes sense. b. Anyone using these functions will be a more advanced user and understand when blocking is / is not needed. In order to land this PR earlier for users who need this functionality, tests will not be added. They will be added in a follow-up as part of #168. Fixes #81 Fixes #247
slimsag
added a commit
that referenced
this issue
Dec 1, 2019
This PR adds support for rendering into arbitrary DOM nodes in the same way that rendering into the `body` worked previously, with one exception: blocking. `RenderBody` remains blocking, since it effectively becomes a helper that 90% of Vecty applications will rely on, whereas `RenderInto` and `RenderIntoNode` which are introduced in this PR do not block. This is because: a. Anyone rendering Vecty into arbitrary DOM nodes will likely want to do it more than once, so making the API of these functions non-blocking makes sense. b. Anyone using these functions will be a more advanced user and understand when blocking is / is not needed. In order to land this PR earlier for users who need this functionality, tests will not be added. They will be added in a follow-up as part of #168. Fixes #81 Fixes #247
slimsag
added a commit
that referenced
this issue
Dec 1, 2019
* Add support for rendering into non-body DOM nodes This PR adds support for rendering into arbitrary DOM nodes in the same way that rendering into the `body` worked previously, with one exception: blocking. `RenderBody` remains blocking, since it effectively becomes a helper that 90% of Vecty applications will rely on, whereas `RenderInto` and `RenderIntoNode` which are introduced in this PR do not block. This is because: a. Anyone rendering Vecty into arbitrary DOM nodes will likely want to do it more than once, so making the API of these functions non-blocking makes sense. b. Anyone using these functions will be a more advanced user and understand when blocking is / is not needed. In order to land this PR earlier for users who need this functionality, tests will not be added. They will be added in a follow-up as part of #168. Fixes #81 Fixes #247
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Will need to make our testing suite much less verbose for this. Ideally we will just perform some Vecty operations in the test suite (e.g.
RenderBody) and get an output list of strings or something non-verbose of exactly which DOM operations occurred.Things we should also ensure we have tests for:
RenderInto/RenderIntoNode)The text was updated successfully, but these errors were encountered: