-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Clean up tests #3248
Comments
As mentioned above 5603b0e |
I agree with this, I think a clean up outline is in order. |
@rafde moreover, I'm working with behaviors also. |
I think the best way to approach this work might be to start testing the things with the least amount of dependencies. So I'd think we could make a utils directory (just have the test folder structure mirror the src) and make a unit test for each file... most likely by pulling from and updating older tests.. I think we can possibly ignore CollectionView, CompositeView, and AppRouter stuff for now. |
Sounds really good 👍 . It will be easy to find test file if it be a mirror of src folder. In addition, starting with behaviors was just experiment how it can goes, importing stuff from src etc. |
I think for large classes with lots of integrations we can break up the tests into multiple files, but they can be put in a folder that matches the file name. live |
Some of the specs could probably be renamed also, like https://github.com/rafde/backbone.marionette/blob/e887d160ea8df451f36bd8474b17edd59648b14e/test/unit/view.triggers.spec.js#L1-L1 is actually testing from |
SGTM |
Maybe we should make a project for this? I've never tried it. |
I tried to do that |
Looking over the tests many of them use older terms (some even Marionette v1). There are a few tests that were modified to match the current behavior, but aren't in fact testing anything anymore. And in general the tests could be updated to be cleaner and more consistent.
Further I believe most of the tests should be organized by class and then by either a feature of that class or an integration with a mixin or other class. We have too many one-off test files that it is difficult to tell where to add something.
I'll be playing with organization and style of tests while writing new ones for #3244 while examining what is currently there. I just want to be thinking about what improvements can be made.
Additionally there's a Readme file in the test directory that is completely irrelevant to our current setup. 😞
The text was updated successfully, but these errors were encountered: