You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Try to avoid using mocks as much as possible. Make "real" objects more test-friendly. Reduce dependency between objects. If mocking is unavoidable, mock not the whole object, but just a part of it (i.e. a method).
We could use the following principles to achieve this:
Try to straighten links between object to make them less dependent on each other (I've made some modifications of the kind within the UI controller to achieve this and make testing easier).
Try to write a "defensive" code. If thee is an external dependency, assume that it may not be valid and provide reasonable defaults that may make the component functional regardless. This is probably mostly important for the Vue components. If something refers to moduleX.itemA assume that both may not exist. This would probably require instead of referring to moduleX.itemA directly in the template create a computed prop. Inside a computed prop we can check if moduleX.itemA exists and if not, return a default value. Computed props may make the testing easier: instead of examining an HTML template (which might be slow in Jest), we can check a return value of computed props. We might also be probably able to mock individual computed props if necessary.
Modules can, along with its class, export the Vuex settings object that is used to create Vuex modules. With this, we can import Vuex settings in the test environment and create Vuex store modules without creating heavier module object (i.e. PopupModule, PanelModule, etc. being the heavier object vs. the Vuex settings) itself.
We should think about exposing public API of modules in a way similar to exposing Vuex settings objects. That will allow for other objects to use an API without creating a module itself.
Reorganize methods to make objects more testing friendly. Create methods that can be mocked easily, if necessary. It's better to mock a simple method than the whole object.
What do you think about the approaches described above?
@balmas, @irina060981: What if we use the following approaches to testing?
Try to avoid using mocks as much as possible. Make "real" objects more test-friendly. Reduce dependency between objects. If mocking is unavoidable, mock not the whole object, but just a part of it (i.e. a method).
We could use the following principles to achieve this:
moduleX.itemA
assume that both may not exist. This would probably require instead of referring tomoduleX.itemA
directly in the template create a computed prop. Inside a computed prop we can check ifmoduleX.itemA
exists and if not, return a default value. Computed props may make the testing easier: instead of examining an HTML template (which might be slow in Jest), we can check a return value of computed props. We might also be probably able to mock individual computed props if necessary.What do you think about the approaches described above?
Originally posted by @kirlat in alpheios-project/alpheios-core#494 (comment)
The text was updated successfully, but these errors were encountered: