Remove JS testing packages

[ash123456789]

I think we should remove Enzyme and Jest from the boilerplate since we have not used them in any projects to date and are not required at all in 99% of our projects. We are even only just starting to integrate Laravel Dusk tests as a standard.

Writing tests is a time consuming process in the first place even when we're strictly using Laravel Dusk and adding in additional tests using Jest on top of that is unnecessary when Dusk gets the job done in pretty much all instances. The majority of our projects use Blade and Laravel with the occasional bit of React thrown in here or there for certain components that absolutely require it.

If we find that we are using React for entire projects which render many pages on the majority of projects then I am all for adding it back into the boilerplate. Right now though, Jest and Enzyme are not being used at all and is basically unnecessary bloat.

[AlexCatch]

Enzyme and Jest should be used more often, it's part of the push to ensure we have consistent tests across the board and while browser tests are good, unit testing of components is another crucial part of the testing strategy.

I could understand Enzyme being removed as projects aren't strictly always React although as we are making a push to use just React as the frontend of choice I believe it should stay.

The argument to remove Jest seems to stem from the point that we're only going to be using browser tests for our testing strategy which we haven't decided yet, unit tests I feel should almost be as important as browser tests when it comes to React and I'd favour them above browser tests to ensure that a component works and renders correctly in insolation.

React and other front end frameworks are used in over 90% of the projects we make and they deserve to have a strong testing environment tailored to it as often the frontend code is almost as big as the backend code.

[ash123456789]

Enzyme and Jest should be used more often, it's part of the push to ensure we have consistent tests across the board and while browser tests are good, unit testing of components is another crucial part of the testing strategy.

I understand that tests are great but what is happening right now is that too many forms of testing are being integrated far too quickly and all at once. Starting off with Laravel Dusk is great and I absolutely agree that testing is necessary. I believe we should start off with getting consistent usage of Laravel Dusk before integrating more forms of testing.

I could understand Enzyme being removed as projects aren't strictly always React although as we are making a push to use just React as the frontend of choice I believe it should stay.

React is absolutely the front end of choice, but it is not necessary for the majority of our projects and is only really being used for very specific components.

The argument to remove Jest seems to stem from the point that we're only going to be using browser tests for our testing strategy which we haven't decided yet, unit tests I feel should almost be as important as browser tests when it comes to React and I'd favour them above browser tests to ensure that a component works and renders correctly in insolation.

I don't believe we're only going to be using browser tests as our testing strategy. What I'm saying is that you're attempting to integrate far too many testing suites and forms of testing in all at once rather than going one form of testing at a time to ensure people get to grips with the testing suite and they understand the process behind it.

React and other front end frameworks are used in over 90% of the projects we make and they deserve to have a strong testing environment tailored to it as often the frontend code is almost as big as the backend code.

React is indeed used in a lot of our projects but the majority are just plain Blade, jQuery and Laravel. React is only dropped in where needed, aside from the projects you have done.

[AlexCatch]

@dextermb @ash123456789 I'm open to the idea of having different "testing packages" that can be added into a project via NPM or composer that just work and require no additional set up.

That would be a nice avenue to explore and would mean we can remove quiet a lot from the boilerplate that doesn't fit the core purpose of what we do.

[jaredkove]

This should stay open until everyones had their say IMO - I don't think anyone has used those testing frameworks internally so is a valid discussion point.

[AlexCatch]

It was closed due to what you mentioned in our slack messages as it mentioned our internal projects. I assumed that closing the issue would give me a route to delete it to avoid history being visible in the comments.

It was not closed to stifle discussion.