Is there any tool which can be used to test that implementations follow FIPS 140-2 Compliance ?
Be very aware that "FIPS 140-2 Compliance" is misleading, and usually irrelevant. To be compliant just means that your software uses a FIPS 140-2 Certified cryptographic module, and getting your software certified costs anywhere from $20-200k and takes 6-18 months. Just because your system passes the self-tests and statistical checks mandated by the standard does not mean it is compliant: the standard says you have to have a certification.
(For what it's worth, the tests mandated usually consist of a few test vectors and some statisitcial checks on the PRNG, and aren't actually too hard to code up, but they aren't enough to claim complance. For that you need the certificate.)
Also be aware that FIPS compliance does not guarantee security or even mean your system is more secure. In fact, it can easily lead to less security by mandating that more secure (but uncertified) algorithms be turned off. Furthermore, FIPS compliance is available at several levels, and software alone can only be certified level 1. Level 2 requires that your software be part of a tamperproof hardware module, and is commensurately more expensive.
The typical solution in a commercial environment is just to license an already certified crypto module, but you're in luck: the OpenSSL team has gotten the source code of certain versions, when compiled in certain ways, certified, and since it's open source, you too can use it--and its certification--for free.
I don't mean the whole OpenSSL library, mind you, just the crypto module; that means it provides AES and RSA and stuff like that, but no TLS or X.509. Those are just protocols built on top of cryptographic primitives, and FIPS 140-2 applies only to the primitives. As long as you use the certified module for all your crypto and PRNG needs, you can use whatever you want for the TLS and other stuff; OpenSSL is an obvious choice, but you can roll your own as well. The only restriction, beyond some rather specific compile-time options and procedures, is that the module must be statically linked.
Do be aware the certified version of the OpenSSL FIPS module is usually pretty old; if you use the rest of the library with the same version, you're going to be in trouble, because last I checked it still contained bugs like Heartbleed. (Note that Heartbleed is a bug in the TLS part of OpenSSL, and thus FIPS has nothing to do with it at all.) Luckily, it's usually possible to use an older-versioned module with a newer-versioned copy of OpenSSL.
Edit: Oh yeah! Be aware that FIPS 140-3 should be coming out soon (read: was supposed to come out in August 2013), and that will supersede 140-2, requiring new certifications and probably meaning you have to switch crypto module versions.
Edit 2: Also, be aware that using FIPS compliant crypto usually sends performance into the toilet because of all the self-testing. (For example, the OpenSSL FIPS module on an iPhone is 100-1000 times slower than the built-in crypto.) If this encourages you to use shorter keys or encrypt less stuff or use a naive pre-encryption compression algorithm, that's a Bad Thing(tm) and has just reduced your security.
No, there isn't. There are too many different systems out there to make a generic tool.