docs: update with latest fixes (#2116)
This commit is contained in:
parent
b9f65c2fdd
commit
6fb77b7771
28 changed files with 276 additions and 89 deletions
|
|
@ -58,7 +58,7 @@ Generally speaking, there are two ways to write tests: upfront and after the fac
|
|||
|
||||
Writing tests upfront requires specifications to be frozen. Upfront tests are a great way of codifying the rules that a yet-to-be-implemented API must obey. However, writing tests upfront may not be a suitable strategy if you don't have a reasonable idea of what your project will look like, if the scope of the API is not well known or if it's likely to change (e.g. based on previous history at the company).
|
||||
|
||||
Writing tests after the fact is a way to document the behavior of a system and avoid regressions. They are useful to ensure that obscure corner cases are not inadvertedly broken and that previously fixed bugs do not get re-introduced by unrelated changes.
|
||||
Writing tests after the fact is a way to document the behavior of a system and avoid regressions. They are useful to ensure that obscure corner cases are not inadvertently broken and that previously fixed bugs do not get re-introduced by unrelated changes.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -74,7 +74,9 @@ var m = require("mithril")
|
|||
|
||||
module.exports = {
|
||||
view: function() {
|
||||
return m("div", "Hello world")
|
||||
return m("div",
|
||||
m("p", "Hello World")
|
||||
)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
@ -90,7 +92,7 @@ o.spec("MyComponent", function() {
|
|||
|
||||
o(vnode.tag).equals("div")
|
||||
o(vnode.children.length).equals(1)
|
||||
o(vnode.children[0].tag).equals("#")
|
||||
o(vnode.children[0].tag).equals("p")
|
||||
o(vnode.children[0].children).equals("Hello world")
|
||||
})
|
||||
})
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue