Plans for testing framework? #8
Comments
|
First of all, thanks for the offer! It is partially by design that we do not have tests from the start just to show how Roc works. 🙂 We actually have a test plugin https://github.com/rocjs/roc-plugin-test-mocha-karma-webpack and just by installing it in you project you should get a new command named After installing it just create a folder named We are missing some documentation here and it should probably be included by default in the template to make it even easier to get started with tests as you say. If you want to create a PR that adds this plugin to the template with some default test that would be awesome! We are working on making the documentation better and I will publish a article on Medium tomorrow that also walks through this process. If there is any issues I'm more than happy to provide a more detailed example. |
|
I'll have a look tonight! Shouldn't be a big job :) |
|
Turns out the big job is finding a testing workflow with expect.js which allows me to test dom elements. Or even access dom elements. |
|
We should give that a little think. I'm not sure if a dom-test-lib should be included in the plugin. This is very dependent on the type of application you want to test and personal preferences. My vote goes to leave that outside of the plugin scope. What do you think @dlmr ? |
|
I agree in that we need to think about what makes sense to provide from the plugin. We want sane defaults and solve the most common use-cases and not create unnecessary abstractions that just creates another layer of complexity. We also need to think twice when making selection about things that can be highly personal, like testing frameworks to some extent. Some things might also be good to add to another plugin, if it is repetitive work that can be abstracted. With that said, for some applications there will be a need to access DOM elements and it might be smart to provide a good pattern for that. For a React application, like this template, this is probably not as needed and things like Enzyme and React Test Utils can be used. In the case of expect there is a extension that makes it easier, however not a way to select DOM elements. https://github.com/mjackson/expect-element However that can be done easily with just |
|
Unfortunately document.querySelector, document.getElementById and all of those are failing for me. They all return null. I'm sure there's a way around it, but I can't find it. Full application.test.js: As for JSX testing, I assumed you would want that in a separate plugin, since that would make sense in templates for components as well as web-apps. Shallow rendering with either enzyme or expect-jsx. |
|
I am currently learning about React testing, mostly because of this issue :) Enzyme seems like it has momentum, but if anyone would like to suggest react-addon-test-utils instead, feel free to wow me. Otherwise, expect a PR in the near to far future... |
|
Cool that you are learning about it :) If you get something up and running that you like be sure to let us know. |
|
Getting stuck on small things still. So when I put this in my roc.config.js: I get this when I run There are two problems here: the first is that I don't necessarily understand your hooking system, the second is that I don't understand why I should have to understand it. I shouldn't have to use hooks, the hooks should be in the plugins with a simple if(config.webpack) then Object.assign(default.webpack, config.webpack)... Shouldn't it? Also, this could alternately be solved with a roc-plugin-webpack-enzyme which solved these problems for me, but I don't have the skills to make that one yet. Though I am learning... Edit: Oh, background on enzyme/webpack: http://airbnb.io/enzyme/docs/guides/webpack.html |
I agree with you to 100%! This is something that should "Just work™️". Unfortunately we are not where we want to be in terms of this and it's of the highest priority to both make this better and document everything around it.
Yes, this should be managed at a higher level to simplify what needs to be done in applications. About trying to getting it to work, try this: |
|
Yep, that did it. Enzyme is still not working, but at least now the hooks are in the right place so I can debug it properly :) |
|
Sigh, that didn't last long. I'm not sure if this one is the "next" error, or if this is simply one that was hidden by the last one.... Or even if this is a roc error or just a webpack error... |
|
Looks like externals is assumed to be an array here, not sure that this is the problem but try to change to that. Could you push what you have locally somewhere? I might be able to take a look at it this weekend. |
|
Hehe, that's basically all I have :) I'm still trying to do a simple test on the normal react-web package. it'll be on https://github.com/tofagerl/playground in a few minutes. Webpack should take an object as externals, but I can reformat this into an array... (Edit: Nope, same error) |
|
Yeah, it will take a object but I might think something else is using an array as the value here and that means that we are overwriting something here. |
|
Oh, so you need to reformat that array into an object if the user passes an object... |
|
This will be easy to manage with a new way to manage "project level configuration" but we are not there yet. So yes, Roc should definitely handle this. |
|
This in your action: () => (rocObject) => {
if (rocObject.hook === 'build-webpack') {
const externals = {
'cheerio': 'window',
'react-dom': 'window',
'react/lib/ExecutionEnvironment': true,
'react/lib/ReactContext': true
};
return () => () => {
rocObject.previousValue.buildConfig.externals = externals;
return rocObject.previousValue;
};
}
} |
|
Yep. Should be able to figure out the rest now.. |
|
And no... That actually breaks |
|
Something like this should work: action: () => (rocObject) => {
if (rocObject.hook === 'build-webpack' && rocObject.settings.build.mode === 'test') {
const externals = {
'cheerio': 'window',
'react-dom': 'window',
'react/lib/ExecutionEnvironment': true,
'react/lib/ReactContext': true
};
return () => () => {
rocObject.previousValue.buildConfig.externals = externals;
return rocObject.previousValue;
};
}
}Edit: I was a bit quick here, this should be better. |
|
Ended up with this: Seems to work with both. |
|
That will work but you will get those externals also in |
|
which I don't want... |
|
Look at this #8 (comment) Added a check for the build mode. |
|
Ah, that comment showed empty for me until I reloaded. |
This is really interesting, but I can't help noticing that there is no testing framework set up as default. Is this on the agenda?
Personally I find the testing part to be the worst part of the whole boilerplate madness, since you always end up needing plugins like jquery, and each plugin is responsible for documenting how it's configured.
And if you're using something other than Karma, well... good luck!
Anywho, will you be adding a Karma config with some generic tests for the included default components to verify that it works out of the box?
I could do a PR, of course, but I'm so bad at configuring Karma it would probably end up failing everything...
The text was updated successfully, but these errors were encountered: