Skip to main content
replaced https://vuejs.org/v2 with https://v2.vuejs.org/v2
Source Link

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.
  • The React testing documentation has some examples for Jest and Enzyme.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

Just like with any other test-automation the majority of your tests should be around 75% unit-tests, 20% integration tests and only 5% blackbox-ui tests. I like the measurements of the Eiffel-tower for the balance.

Testing explained for the other frameworks:

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.
  • The React testing documentation has some examples for Jest and Enzyme.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

Just like with any other test-automation the majority of your tests should be around 75% unit-tests, 20% integration tests and only 5% blackbox-ui tests. I like the measurements of the Eiffel-tower for the balance.

Testing explained for the other frameworks:

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.
  • The React testing documentation has some examples for Jest and Enzyme.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

Just like with any other test-automation the majority of your tests should be around 75% unit-tests, 20% integration tests and only 5% blackbox-ui tests. I like the measurements of the Eiffel-tower for the balance.

Testing explained for the other frameworks:

added 343 characters in body
Source Link

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.
  • The React testing documentation has some examples for Jest and Enzyme.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

ForJust like with any other test-automation the majority of your tests should be around 75% unit-tests, 20% integration tests and only 5% blackbox-ui tests. I like the measurements of the Eiffel-tower for the balance.

Testing explained for the other frameworks:

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

For other frameworks:

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.
  • The React testing documentation has some examples for Jest and Enzyme.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

Just like with any other test-automation the majority of your tests should be around 75% unit-tests, 20% integration tests and only 5% blackbox-ui tests. I like the measurements of the Eiffel-tower for the balance.

Testing explained for the other frameworks:

Source Link

I have worked with a couple of JavaScript front-end frameworks (Angular, Ember and React) an all of them have their own tools to write (whitebox) tests. The (included) test frameworks let you render the components in isolation letting you verify their behaviour without the need of a browser. Letting you write unit like tests, but also integration tests.

Currently we are working with React:

  • Jest is the test framework Facebook maintains themselves.
  • Enzyme let's you render the component in a shadow-dom to check the components behaviors easier.

I would try to prevent to write all your tests with Selenium. Personally we only write one end-2-end test for each feature we build. Just to make sure it is testable and so that we test the happy-path end-2-end.

For other frameworks: