优秀的测试用例具有三个重要的特征：
1.可重用性（repeatability）——测试结果应该是高度可再生的。多次运行测试应该产生相同的结果。如果测试结果是不确定的，那我们又如何知道哪些结果是有效的，哪些又是无效的呢？此外，可重现性可以确保我们的测试不依赖于外部因素（诸如网络或CPU负载）。
2.简单性（simplicity）——测试应该是只专注于测试一件事，在不影响测试用例目的的情况下，我们应该尽可能消除过多的HTML标记、CSS或JavaScript。我们删除地越多，测试用例只受特定代码影响的可能性就越大。
3.独立性(independence)——测试用例应该独立执行。我们必须避免一个测试结果依赖于另外一个测试结果。把测试分解成尽可能小的单元，这将帮助我们确定在错误发生时的确切代码位置。
有很多方法可以用于测试，有两种主要的方法分别是解构型测试和构建型测试。
JavaScript代码测试有很多分类，比如单元测试(unit test)、集成测试(integration test)、功能测试(functional test)、端到端测试(end to end test)、回归测试(regression test)、浏览器测试(browser test)…
单元测试
单元测试指的是测试小的代码块，通常指的是独立测试单个函数。如果某个测试依赖于一些外部资源，比如网络或者数据库，那它就不是单元测试。
单元测试一般很容易写。一个单元测试通常是这样的：为某个函数提供某些输入值，然后验证函数的返回值是否正确。然而，如果你的代码设计非常糟糕，则单元测试会很难写。从另一个角度理解，单元测试可以帮助我们写更好的代码。
从某种意义上，单元测试就是代码的骨干。通过单元测试，可以帮助你优化代码设计，可以保证修改代码时正确无误。
单元测试可以帮助我们避免一些常见的BUG。通常，程序员会在同一个细节上反复犯错，如果为这些BUG添加单元测试，则可以有效避免这种情况。当然，你也可以使用集成测试和功能测试来解决这个问题，但是单元测试更加适合，因为单元测试更加细致，可以帮助我们快速定位和解决问题。
什么时候应该做单元测试呢？采用测试驱动开发(test driven development)的话，你应该一直写单元测试。好的单元测试不仅可以避免BUG，还可以优化代码，并且保证修改或者重构代码时不会出错。
流行的JavaScript单元测试工具有Mocha, Jasmine和Tape。
集成测试
集成测试就是测试应用中不同模块如何集成，如何一起工作，这和它的名字一致。集成测试与单元测试相似，但是它们也有很大的不同：单元测试是测试每个独立的模块，而集成测试恰好相反。比如，当测试需要访问数据库的代码时，单元测试不会真的去访问数据库，而集成测试则会。
单元测试不够时，这时就需要集成测试了。当你需要去验证两个独立的模块，比如数据库和应用，保证它们能够正确的一起工作，这时就需要集成测试了。为了验证测试结果，你就需要通过查询数据库验证数据正确性。
集成测试通常比单元测试慢，因为它更加复杂。并且，集成测试还需要配置测试环境，比如配置测试数据库或者其他依赖的组件。这就使得编写和维护集成测试更加困难，因此，你应该专注于单元测试，除非你真的需要集成测试。
你需要的集成测试应该少于单元测试。除非你需要测试多个模块，或者你的代码太复杂时，你才需要集成测试。并且，当你的代码过于复杂时，我建议优化代码以便进行单元测试，而不是直接写集成测试。
通常，我们可以使用单元测试工具编写集成测试。
功能测试
功能测试有时候也被称作端到端测试，或者浏览器测试，它们指的是同一件事。
功能测试指的是测试应用的某个完整的功能。对于网页应用，功能测试意味着使用工具模拟浏览器，然后通过点击页面来测试应用。
单元测试可以测试单个函数，集成测试可以测试两个模块一起工作。功能测试则完全是另外一个层次。你可以有上百个单元测试，但是通常你只有少量的功能测试。这是因为功能测试太复杂了，难于编写和维护。功能测试很慢，因为它需要模拟真实用户进行网页交互。
事实上，你不需要编写非常详细的功能测试。功能测试并不意味着你需要测试每一个功能，其实，你只需要测试一些常见的用户行为。如果你需要在浏览器中手动测试应用的某个流程，比如注册账号，这时你可以编写一个功能测试。
对于单元测试，你会使用代码去验证结果，在功能测试中也应该这样做。以注册账号为例，你可以验证浏览器是否跳转到了”感谢注册”页面。
当有些测试你需要手动在浏览器下重复进行时，你应该编写功能测试。注意不要写得太细致了，否则维护这些测试将是一个噩梦。
最流行的功能测试工具是 Selenium。Selenium WebDriver或者Protractor通常与Selenium一起使用，有时也使用PhantomJS和CasperJS，注意你不需要使用真实浏览器。