I would rather go through a burning building than doing a single line of code that is for test automation in Salesforce. Salesforce is the biggest sin of humanity.

Maybe I'm already in hell, I don't mind it!

@C0D4 Do you have cool laptop stickers there?

@llcamp laptop stickers? I can't stand them on a laptop.

We have card games though.

Worse than IE6, GDI, UEFI, YAML, PHP5, VBA, PL/SQL, cmake, XSLT, x64 ASM, etc.?

@Root it has its limits, and enforces you to stick to best practises all the time, but beyond that, I'll take it over IE6 anyday ☺️

It's not something you can half ass an implementation with though, and that's where to pain comes most of the time.

Testing can be a real pain if your doing anything that needs to run as users, as tests then need to adhere to record access and permissions which can get complicated depending on the scenario.

@C0D4 Sounds like my every day specs. 🤷🏻‍♀️

@Root sadly, the half assed implementations seems to be the norm with SF Devs and then they get into the deep end when the platform starts throwing you under a bus ☹️ - from my experience anyway.

Is sales force that bad? I’ve never used it but I thought given how much they make it was a great tool >.>

@pandasama it can be.
Out of the box and basic customisations, it's a great platform.

There's many ways to add customisations with or without code, but each method has its inherited pro's and cons which are important to understand and how they all stack.

For example, this one page is my holy bible.

https://developer.salesforce.com/do...

They document virtually everything, to some extent and they also have the trailheads side of things, think interactive documentation / playgrounds

The problems start to pile up when the devs, admins or who ever, don't understand the impact and consequences of what they are adding and just add things to cover their use case - this is what I've come to see hired help do.

Everything you do MUST - which is a problem for large customisations - fit inside their governing limits.

https://developer.salesforce.com/do...

These are essentially hard coded limits that can murder your implementation with multi object chained (tables) changes.

But overall, if you know it's limits, and can get creative to stay under-them and keep everything running smoothly, you can do a lot with it.

@C0D4 Thank you for the informative response! I think I get a good idea of it now, it still has a learning curve but if you take that time it’s plenty useful over doing it from scratch yourself, is that right?

@pandasama that's debatable still, but for enterprise it's probably better long term - although expensive as most licensing is based on active users, Salesforce does updates every few months, and warn you well in advance of any breaking changes - although you can ignore some of those if it's code related as each class can be versioned against their api versions and not be affected until you're prepared to push that class to the newer api versions.

They also have the app exchange, think marketplace for 3rd party vendors, which can be handy if the dev team isn't capable or have the time to implement some major functionality - but that can come down to cost vs time.

The worst part, would be the complicated tests you may have to write and keeping the system stable and inside the governor limits.

@C0D4 Sounds like a completely different way to work with it’s own challenges, personally doesn’t sound very tempting >.> but that’s just me, thank you!