06-06-2019 05:44 PM
06-06-2019 05:44 PM
Every couple of years there's a SharePoint developer who publishes a few posts talking about a unit testing framework working with SPFx.
While I can absolutely understand the value of unit tests in large code bases or in complex solutions, I do struggle to justify the overhead when it comes to SharePoint components.
These are, at least in our context, a series of single purpose independent components, where the core of the effort is on the UI layer.
The overhead of mocking up all the different lists and libraries that are often part of the solution is quite significant, and as those instances change quite rapidly as we put them in the hands of the user, keeping all tests up to date, passing and relevant quickly adds up.
Is it really worth the investment of time in teaching the team how to use a testing framework, integrating it on our practices, and accepting the overhead on every small piece of work?
For those of you out there using SPFx in anger, are you using TDD, or planning to use it?
Do you think it brings to SharePoint development the same level of benefits that it brings to full custom developed apps? Any particular framework that gels well with SPFx that you think I should absolutely be looking into?
Thanks in advance for your help and advice.
06-07-2019 06:44 AM
@Jorge Carvalho The age old question and something that not enough people do in my opinion :) It's one of those "depends" scenarios, where, if you are okay with not Unit Testing, that's entire up to your development team and practices. It's valid to feel there is a bit of overhead because of the upfront work to do the unit tests. I think you'll see more ISVs or businesses with a product that will heavily use Unit Tests.
I like the benefits of Unit tests, and if you are going to do unit tests, look into using JEST. I'm sure you've seen them, but Elio has some great posts on this.
06-10-2019 06:02 AM
Thanks @Beau Cameron
I agree that if you have a large complex product, you definitely get value from a solid test harness.
But if you're building small independent apps, with very specific purposes, often tactical disposable solutions, the impact on cost and time to release are harder to justify.
Leaning towards the simpler approach at the moment but I think I'll have to argue with myself on this one a little longer.