No. There is no good way to detect backdoors in cryptographic hardware. There are too many ways to hide backdoors so they won't be detected.
Testing is not an effective way to detect deliberately-introduced backdoors. An attacker can easily arrange for the backdoor to be activated only for particular text, or only after receiving a special "cryptic knock". For instance, the hardware engine might have a 64-bit secret value hidden in it. Initially, the backdoor is disabled. However, if it receives a ciphertext starting with the 64-bit secret, then that's the "cryptic knock"; when the "cryptic knock" is received, the hardware engine can switch on the backdoor. This enables an attacker to enable the backdoor some time after the system enter production. Similar means could also be used to allow an attacker to dynamically target specific communications or otherwise evade detection.
There are many ways that a malicious crypto engine could subvert your security. If you use it to generate random numbers or crypto keys, it could "spike" the random-number source and generate keys that will be guessable to the attacker. If you use it to verify the integrity of signed message, it could potentially falsely accept certain malicious messages when signalled to do so by the attacker. If you use it to encrypt confidential data, it could potentially leak the confidential data to the rest of the world in a number of different ways. If it has direct network access, it could leak confidential data and keys by simply sending it out over the network. If it doesn't have direct network access, it could still conceal confidential data or cryptographic secrets in the ciphertexts and leak this information out over a subliminal channel (for instance, taking advantage of the degree of freedom in the choice of a nonce, IV, or other random value to hide secret data in them).
And even if it can't do any of that, a malicious crypto engine could still leak confidential data or cryptographic key material out using a timing channel. See Jitterbug for an example of a piece of malicious hardware that exfiltrates confidential data by adjusting the timing of network packets. A malicious crypto engine could use a similar mechanism: e.g., when asked to encrypt something, it delays responding to the request until the low-order bit of the current time in milliseconds matches the bit it wants to send. Thus, the time at which ciphertext packets are sent over the network will leak information about the time at which the crypto engine responded, which in turn conceals a subliminal message that the malicious crypto engine wanted to exfiltrate.
Bottom line: if you don't trust the crypto hardware, there's basically no way to win. So you should only use crypto hardware that you trust.