UNPKG

siesta-lite

Version:

Stress-free JavaScript unit testing and functional testing tool, works in NodeJS and browsers

www.bryntum.com/products/siesta/

82 lines (48 loc) • 3.62 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
General strategy for testing your web application ============================================= This guide describes the strategy to maximize the return of your time investments in testing. Test the model first. --------- You may already have heard the "fat model, skinny view" idiom. It means - put as much of business logic as possible in the Model, don't pollute the View with it. The Model should be completely unaware about the UI and be self-contained. It's not only a clean separation of your code, but you also ensure that you can safely refactor the UI whilst keeping the business requirements intact. This way the model can also be easily tested, w/o involving any the interaction with the UI. By starting your test suite with Model you also limit the scope of uncertainty during debugging. Having the Model well test-covered, you can always say "this bug must be somewhere in the View or Controller". For example. If you have a login form, don't put the authentication logic to the "click" handler of the "Login" button. Instead, you can have an "App.AuthManager" class in your application, which can have a "login" method. Then, in the "click" handler, you will just call "App.AuthManager.login()". Writing the unit tests for your Model is usually very easy and straightforward and has maximal returning effect. If you are not able to test your Model in isolation this is normally a red flag about the design - parts of your app are too coupled together. Test views (individual components) after Model. --------- Second step in testing your application will be to test your views (individual components such as grids and trees). This does not mean you need to use exactly one component class in your test - but use as few classes as required to instantiate and operate on the component being tested. Again, testing the individual parts of your application limits the scope of uncertainty and side-effects. This type of testing requires slightly more effort, but still usually quite easy and returning effect is very good. Test the application as a whole. --------- Finally, test your application as the "black box", exercising all possible side effects. When finding a bug, first try to move the test for it to on one of strategies above. Only if that is not possible write tests at the whole application level. This type of testing is called functional or acceptance testing. It usually requires most effort to implement and maintain, because changes in individual components may break tests. One need to carefully choose the selectors used for simulating user actions, for them to be specific enough, and not dependent on styling (which changes often). Still, this type of tests are must have as well, because they actually indicate the status of your app. You can for example, write a special set of tests to run after the deploy, so you can make an informed decision whether to push the deploy build to production. Buy this product --------- Visit our store: <https://bryntum.com/store/siesta> Support --------- Ask question in our community forum: <https://www.bryntum.com/forum/viewforum.php?f=20> Subscribers can post expedited questions in Premium Forum: <https://www.bryntum.com/forum/viewforum.php?f=21> Please report any bugs through the web interface at <https://www.assembla.com/spaces/bryntum/support/tickets> See also --------- Siesta web-page: <https://bryntum.com/products/siesta> Other Bryntum products: <https://bryntum.com/products> COPYRIGHT AND LICENSE --------- Copyright (c) 2009-2022, Bryntum & Nickolay Platonov All rights reserved.