minimum cardinality tells you what elements must be present in all instances. For example, Observation.status has a minimum cardinality of “1” - that means if you’ve got an Observation, the status element must be present
constraints set rules about conditional requirements. For example, on Patient, there’s a rule that says that if you’ve got a Patient.contact, you must have a name, telecom, address or organization
There’s a base requirement that if an element is present, it must have either child elements or a ‘value’.
if you need to comply with any profiles, you have to pay attention to mustSupport. They don’t set requirements for what “must always appear”, but they do define what you must support. For example, if a profile marks Patient.deceasedDate, that doesn’t say that deceasedDate must always be present, but it would typically mean that your system would have to be able to capture and store it if one applied - and if if the patient had a deceasedDate, then there’d be an expectation it would be present in your instances.
The Java validator is pretty comprehensive for checking instances. There’s no such thing as “conformance testing” against the base specification because the core FHIR specification doesn’t set expectation for what systems need to do. Each organization/community that defines how they want implementers to roll out FHIR need to figure out what degree of testing they want to take on