Integrate unit & behavior tests for the JavaScript-Applications

[Inkdpixels]

The stack will contain at least mocha, chai and sinon, either cheerio or JSDom and maybe even the React testing utilities.

[Inkdpixels]

Tried to setup the TDD infrastructure. Standalone testing via mocha fails for most of the code base, because we currently use the root feature of webpack as well as imports of .css in our .js files.

So basically, we need to use a test runner which accepts webpack as a preprocessor. I've found that Karma works best, and pretty much everyone uses it. Anyway, I am currently stuck at rendering the components into the document with testUtils.renderIntoDocument(), somehow this fails currently. Thus I cannot assert the rendered elements as well as I/O handlers.

But there is another thing to try, react introduced the shallow rendering method, which works good at the moment. But the problem I am facing here is that this feature is not well documented, and karma can't log the results which are returned of the renderer since it contains Symbols (which cannot be converted to a string).

Another thing to note, since karma needs webpack to preprocess the whole bundle, the test suite needs about 10 seconds to boot currently, this is far from acceptable and will lead to devs ignoring the test suite, not good, not good.

TL;DR This whole topic is a mess and I stopped here, I pushed all my changes into a separate branch and will work on that whole thing in the coming days again. Any help appreciated.

https://github.com/PackageFactory/PackageFactory.Guevara/tree/task/18/testSuite

[dimaip]

From my experience it's the easiest to start off writing tests for reducers. And those are much more important than component tests.

[Inkdpixels]

Yeah, you are probably right @dimaip - We should focus on that first.

[dimaip]

Just FYI, back in the days (September actually) when I was starting with Redux, this tutorial helped me a lot with testing: http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

[Inkdpixels]

Alrighty mighty, test-suite is done. Now we can begin to write the tests for the reducers/components/functions/whatsoever.

The stack consists of mocha, chai and jsdom.

Any file which ends with .spec.js will be loaded into mocha and executed. To run the tests, execute npm test.

Also, regarding the tests for compoennts. There is no other way to test stateless components other than with the recently mentioned shallow rendering, so we might have to wait until react incorporates something for stateless components. Issue here: facebook/react#4972

[Inkdpixels]

Note: Another thing which @robertlemke pointed out today, we should create a mock server based on express or the like for the whole UI, to separate the testability from the backend services.

[Inkdpixels]

We might look into testing the behavior with http://www.nightmarejs.org/ & BrowserSync/BrowserStack on CI as well

[Inkdpixels]

Yesterday i played around with the skin-deep package for tests using the shallowRenderer. It worked, but nevertheless I don't think that unit tests for react components are a big benefit for us. Ideally we should remove all of the logic of out of the react components (basically thats done already), and test them separately. Whats left is the pure rendering output, and I seriously doubt it that we should test markup.

Instead we should focus on behavior tests, in multiple environments using karma/browserstack. Even though I dislike the overhead karma brings, it will be the most practical solution since it offers a good integration with BrowserStack.

Still, the biggest priorities should be, that the UI will be as good as possible test covered, and that the tests are run as fas as possible as well to embrace a culture of writing tests not as a feature, but as a requirement instead.

TL;DR I will focus on writing behavior tests in the upcomming days using Karma/BrowserStack.

[Inkdpixels]

Note: Behavior test setup is done. Will add behavior tests in the next two days!

[Inkdpixels]

Alright, setup is pretty much done and kind of "stable", kind of, because you clearly need a good understanding of how the browsers and the setup between CI & SauceLabs works, if that is not the case, you may have trouble setting up user stories because the tests could run without problems locally but may fail due to network problems between the CI & SauceLabs server - This is pretty "meh" and we may need to revisit this later on.

Until then, and until we create bigger user stories together (maybe on one of the following sprints), we should work with the given setup and focus on other tasks.

Alternatives for the future:

• Maybe switch to BrowserStack instead of SauceLabs?
• Or switch the testrunner to http://nightwatchjs.org/ (Though I doubt that this would change the current situation since both of them rely on the WebDriver API)