Interested in adding a section on testing?
pauleveritt opened this issue · 3 comments
Very good article. I think you have a great opportunity to help explain the frontend world to a Python audience. In fact, this article might be good in a version written in Python terms.
Lately I've tried hard to think in terms of writing my (Angular) apps as if the browser doesn't exist. Mainly, TDD in a node/iojs context. My index.js packages then do the imports of Angular and wire everything up. I then use mocha and babel in my tests and get a fast turnaround cycle. No Webpack bundling, etc.
Do you think that would be a good addition to this README? I have a start of it at https://github.com/pauleveritt/sap-then-assert. I could remove the Angular parts, trim it down, and make a few sections for this (very small part, the Promise part, etc.)
Wow, that's quick feedback!
I am interested in adding a section on writing tests.
I've also tried to write React apps (with Redux) in such a way. I focused on testing the state management which is really independent from the browser, but you can test UI components that way as well, though you may sometimes need to simulate more of the browser environment.
I think we may want to split this up into two bits:
- how to test code with mocha and babel without the browser environment.
- how to use stuff like Sinon to mock Promises and such.
I'd like to focus on the first bit first and then worry about the second bit later -- it's not applicable to all code and is a separate issue. We'd need to explain the motivation to writing your tests this way (it's just much easier than a whole browser environment, it helps with loose coupling, etc) and then explain how to write a very simple test that imports your code and run it. Hook it up to npm test. I have my own code for this lying about and I'd like to compare it with yours and pick out the best bits of each.
Concerning doing this in Python terms, would a lot more Python terms be needed to make it comprehensible to Python developers?
I agree with splitting the two issues and dealing with promises separately. Who knows, maybe async/await will soon diminish the prominence of promise-based code.
On the Python part, maybe I’ll make that a separate ticket and talk about it there.
—Paul
On Oct 27, 2015, at 7:07 AM, Martijn Faassen notifications@github.com wrote:
Wow, that's quick feedback!
I am interested in adding a section on writing tests.
I've also tried to write React apps (with Redux) in such a way. I focused on testing the state management which is really independent from the browser, but you can test UI components that way as well, though you may sometimes need to simulate more of the browser environment.
I think we may want to split this up into two bits:
how to test code with mocha and babel without the browser environment.
how to use stuff like Sinon to mock Promises and such.
I'd like to focus on the first bit first and then worry about the second bit later -- it's not applicable to all code and is a separate issue. We'd need to explain the motivation to writing your tests this way (it's just much easier than a whole browser environment, it helps with loose coupling, etc) and then explain how to write a very simple test that imports your code and run it. Hook it up to npm test. I have my own code for this lying about and I'd like to compare it with yours and pick out the best bits of each.
Concerning doing this in Python terms, would a lot more Python terms be needed to make it comprehensible to Python developers?
—
Reply to this email directly or view it on GitHub #1 (comment).
Besides async/await just having the async code in its own isolated section greatly diminishes how important it is it to mock promises. I see this in code that uses the Flux pattern where you have action creators, such as in Redux. The only async code is in the action creators, nowhere else.