The Yeaoman @microsoft/[email protected] comes with no scaffold support for tests files for React and JavaScript client side solution templates. That feature was present in older versions and was useful to 3 teams within my organization.
What might be the reason for removing that from a newly created web part scaffolded by the Yeaoman generator?
Maybe option for including the test folder and test file in the solution upon creation could be beneficial. Something similar to Visual Studio that has check box allowing to include Tests project in your C# solution upon solution creation.
Thx @VelinGeorgiev for reporting, let me follow up on this internally. We should definitely not remove anything without proper documentation in release notes.
Hi @VelinGeorgiev , so the problem was that the test code present was insufficient, and took up a lot of space (40+ megs in node_modules I believe). The general feedback was that it was not useful to include.
We do want to provide a better test story for SPFX components. It would be super helpful to us if you could comment in user voice (https://sharepoint.uservoice.com ) with what you would look for. Thanks. (closing this issue)
@VesaJuvonen , @patmill do you know what would be the future of the SharePoint testing framework and packages so we can eventually plan migration if that would be deprecated. We have thousands of tests using npm packages provided by the SharePoint Framework and using the SharePoint Framework built-in gulp tasks and karma configs. If that will be deprecated, better have official announcement so whoever is using it to have time to migrate to custom testing setup.
Ideally, wouldn't it be the best if the SharePoint Framework allowed us to use any testing framework we want? There are quite a few testing frameworks available out there and everyone has their own preference. As long as things just work and developers can use the testing framework of their choice, I'd say it's not necessary for Yeoman to scaffold tests by default.
I agree with that. But my assumption based on the @patmill comment is that all the OOTB packages related to the testing will be dropped including phantomjs, karma setup and gulp setup. For me that means 40+ mb, not just the scaffolded files, if that is the case it should be officially communicated because the ootb setup for testing is in use.
We decided to use it and if this is going to be deprecated, it would require technological time for us to migrate.
@waldekmastykarz - Will you create a user voice entry for your recommendation? Myself and my colleagues will up vote it.
stumbled on this issue recently trying to debug unit tests with 1.4.1 and see what's missing. Agree with the fact that spfx should be "test framework agnostic" and let the community provide samples for different options. My original post from almost a year ago https://github.com/SharePoint/sp-dev-docs/issues/736
I also agree with the fact that SPFx should be test framework agnostic and infarct we already have PnP sample and examples how the Jest testing framework can be setup.
I decided to use the Jest instead of the OOTB provided by the #SPFx. That worked for me and I use it in all my projects now.
There is a PnP sample http://bit.ly/2Hiy4qb , but you can find guidance at http://bit.ly/2T08ho1 or http://bit.ly/2szHzXO or http://bit.ly/2QUZ4LR
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues
Most helpful comment
Ideally, wouldn't it be the best if the SharePoint Framework allowed us to use any testing framework we want? There are quite a few testing frameworks available out there and everyone has their own preference. As long as things just work and developers can use the testing framework of their choice, I'd say it's not necessary for Yeoman to scaffold tests by default.