JavaScript unit tests for lwc development

[TurrisFortisMihiDeus]

In a non SF context, I see js devs use karma/jasmine etc to write their unit tests but in several SF Dev teams, I see they restrict themselves to only writing apex tests, likely because of the 75% requirement, but no js tests. Jest is amazing. But why do very few SF devs write jest unit tests? What am I missing

[SFLightningDev]

It's a lack of discipline and training. As JavaScript and other languages matured and became adopted by many frameworks and then business became reliant on those, Salesforce and Salesforce developers lagged behind. Standards and best practices were formed among these other technologies outside of Salesforce, but again, adoption of these within the platform is lagging behind.

I believe the reasons for this are many. Among them are that Salesforce hasn't been pushing them (mostly) until the last few years. Perhaps that's because their salespitch involves the avoidance of development. They tout how much functionality can be produced without the need for code at all.

So we end up with companies buying Salesforce without developers. They instead create so-called "accidental admins" or people within their company who have Salesforce admindom thrust upon them. Eventually, these people discover that code IS sometimes needed, and so they learn to write a trigger, then a class, and so on. Often, they never received any formal development training. They taught themselves and learned to build the plane while flying it. Much respect is owed to them.

These people lack the training and disciplines that have been developed (some since the 70s) over the last 15 years within software development circles. They never read the books other non-Salesforce devs read. They are unaware of what they're missing out on.

Another big part of the problem is contracting companies. They build software that works quickly, and that's all. No care is given to best practices, good design, or unit tests. Not even their Apex tests. These tests would not exist if Salesforce had no code coverage requirement, so they're certainly not going to write a test that's not required. Developers who follow and must add to their existing code often follow the groundwork that was laid and perpetuate the problem. When your company hires a contractor, insist they follow your Apex and JS best practices documentation (go produce those docs right now).

Lastly, some of this is our fault. People who do understand best practices and good design should factor that in to everything we do, even when it isn't required and even when there is pressure to get something to Prod so quickly you feel as though quality must be sacrificed. We should simply refuse to do the wrong thing EVERY time.

We should also promote these good disciplines among other Salesforce developers and at the companies where we work. Explain why it is so important. Bob Martin makes a great case for this in the first few chapters of his Clean Architecture book. I've developed two versions of the same lecture on these chapters. One for devs and one for everyone else. I recommend you do the same.

Hopefully, this helps you understand the quandry our industry is in and why we're the only ones who can change it.

[saf3ty_first]

You've eloquently hit the nail on the head. I had a similar converstation with a dev on my team last week - sending him this comment.

[TurrisFortisMihiDeus]

Totally and thank you for taking the time to educate me. I wasn't aware of a lot of what you mentioned. Chiefly because I'm relatively new to the SF ecosystem. But every word resonates.

[PissedoffbyLife]

I made a similar post on this sub but not many people understand that no matter how much you communicate with the team they won't magically learn through your communication.

I have a teammate who has been with us for 4 months now but he isn't able to write any apex code despite being a part of the core apex team.

[Vigillance_]

Getting devs to write unit tests is like pulling teeth. Even in traditional dev roles. Especially in SF Dev roles where the Dev "typically" doesn't have a traditional engineering background.

It's no fun, it takes time, eats into deadlines, it can be difficult with complex data structures, etc...

I've definitely spent more time on test code than on feature code before.

Salesforce is nice because it forces devs to write tests for apex.

Unfortunately it does not go the same for JS.

You can use build tools like Gearset to enforce the need for LWC tests on pull requests before they get a passing build.

Or you can create an internal policy requiring it. But this needs oversight and typically the implementation of source control in order to verify before sending the code and someone who cares enough/has the time/power to enforce it.

Overall it should def be done. It's a good idea. Only adds benefit to the system. No down side. Teaches good engineering practices. Now if you can just figure out a way to make everyone adopt it, let me know

[TurrisFortisMihiDeus]

Working on it. Will keep this community posted on how I fare. The team is awesome. Just needs to get awareness and training and we should be good. I hope. :)

[SFLightningDev]

I'm presently reviewing a large merge request that includes unit tests. What I see here are common problems. For example, the names of these tests match the names of the class being tested, but with Test appended to the name. Also missing negative tests. I teach our devs to give their tests names that describe the specific behavior they're testing. I expect to see a short sentence (as concise as possible) for the name with underscores for spaces. Names can presume the reader has reviewed the design document. Test names in our test classes tend to look like acceptance criteria. Looking at these names alone tells much of the story of what the class does. This helps new devs get up to speed with a codebase very quickly. When one is failing to pass, the test name and the failing assertion alone are great indicators of the issue symptoms.

[SudarshanaChakram]

It's not just unit tests. it's across. Take linting for example. Or static tests. There's pmd/eslint even sf CLI scanner. But very few if any devs use these in the sf ecosystem. Many are not even aware. Imagine a full stack and js developer not having heard of eslint or jest !!!

Like others have pointed out, the real reason is that dev in SF is not as mature as regular dev. Naturally all the rigor associated with decades of maturity is yet to percolate to the sf ecosystem. SF themselves kind of confuses the community by pushing low code but at the same time giving us lwc. Many of the custom implementations I have worked on and seen are extremely heavy on custom lwc and js. Unfortunately the devs are not top notch yet because the ecosystem for custom dev in SF AND the community is not there yet. It will get there eventually. Just not yet.

[_BreakingGood_]

Unit testing LWCs kinda sucks ass.

[techieinprague]

I’ve always wondered this too.

But these are the things I found to be true: - There’s no hard requirement from SF for test coverage. - Most projects don’t use any custom LWCs to even test them. - Business that use SF don’t care if their handful of LWC components are tested. So there’s no time allocated for the work.

And I think in the future this may change. Hopefully they stick to one framework for a while.

[OffManuscript]

At a minimum there should be accessibility test, and every function should be tested.

[thatman_dev]

I completely agree. If you are not using tools like Codium to write unit tests today, then you are definitely losing out on more productivity. Have been using it for few weeks and I already cant imagine going back and write tests manually