vite-plugin-vue-type-imports
vite-plugin-vue-type-imports copied to clipboard
wheatjs
test: add `vitest` for testing
WIP, DO NOT MERGE, SUGGESTIONS WELCOMED (Ignore the eslint config, I will revert it before merging)
I made the structure of the test directory as follows:
test
├── common.test.ts // test file
├── fixtures
│ ├── common // category
│ │ ├── interface-extends-interface // scenario
│ │ │ └── no-reference // more detailed scenario
│ │ │ ├── index.ts // entry file (types)
│ │ ├── interface-without-reference
│ │ │ └── default
│ │ │ └── index.ts
│ │ └── redeclaration-of-types
│ │ └── default
│ │ └── index.ts
│ └── dynamic
│ └── interface-without-reference
│ └── default
│ ├── index.ts // the type file corresponding to the entry file
│ └── index.vue // entry file (code)
└── in-sfc.test.ts
Some explanations
Currently, I divided fixtures into two main categories:
Common
"Common" means that all tests under this category are based on the same code, which corresponds to the scenario "use the imported type directly". Therefore, only type files are included under this category.
function generateCode(path: string): string {
return `<script lang="ts" setup>
import { Props } from '${path}'
defineProps<Props>()
</script>
`
}
Dynamic
"Dynamic" means that most of the tests under this category are based on different code. The most common scenario is "use the imported type indirectly". We need to read the content of the files and transform them.
Entry file
Each detailed scenario can have multiple entry files to add more constraints.
We will test the entry files with different options, which means that each entry file has multiple tests.
About the name of the tests
Actually, I'm talking about the export name of each test in the snapshot file.
I imagine two ways of naming it.
1
Category > Scenario > Detailed scenario > entry file (options)
Example:
Common > Interface extends interface > No reference > index.ts (normal)
NOTE: The name of scenarios will be normalized. (e.g. interface-extends-interface > Interface extends interface)
2
Category > relative path of entry file > options
Example:
Common > interface-extends-interface/no-reference/index.ts > normal
Maybe I need to implement it and look at the output of running tests before I can decide which way to go. :P
My personal opinion on this
- All tests are based on the function
transform, we may need to test other functions in the future. - At the moment we don't do component testing because I have tried to do so and found that it only gets the name of each prop of the component and not the type of each prop.
I need suggestions (either it's naming, or whatever) to improve it before I implement it.
I don't think component testing will be necessary. We are mostly just doing basic transforms, so as long as we inspect that output after our transform and make sure everything is correct that should be good enough. Also component testing can be pretty complicated and heavy, so I think leaving it as vitest is well enough.
I don't think component testing will be necessary. We are mostly just doing basic transforms, so as long as we inspect that output after our transform and make sure everything is correct that should be good enough. Also component testing can be pretty complicated and heavy, so I think leaving it as vitest is well enough.
That's what I said. :D
I've also updated the comment, do you have any suggestions on it?
This is the error output of the two naming styles when the test encounters an error.
Which one do you think is better? If you have a better solution, feel free to suggest. :D