Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document test strategies #35

Open
balmas opened this issue Jul 28, 2020 · 2 comments
Open

document test strategies #35

balmas opened this issue Jul 28, 2020 · 2 comments
Assignees

Comments

@balmas
Copy link
Member

balmas commented Jul 28, 2020

@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:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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?

Originally posted by @kirlat in alpheios-project/alpheios-core#494 (comment)

@balmas
Copy link
Member Author

balmas commented Jul 28, 2020

@kirlat
Copy link
Member

kirlat commented Jul 28, 2020

Sure, will do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants