Testing microservices is very similar to testing services in general, i.e. you will have a contract (API) and some internal business logic and state and you test that logic and state using the contract by making requests to the service and observe the response.
One thing to note would be that if you have a fully monolithic system you do not need to care about integration between services, since you only have one. Where the more services you have the more integration points you have. Contract Testing is one technology that have popped up.
Another kind of problem that you can get is synchronization which means that changing and deleting stuff would rise on my importance list. The reason for the problem is that in monolithic system you commonly have one main database where everyone writes and read, so it is easier to make sure that every part of you system have the same data. With microservices you typically have plenty of databases. And some of your entities exists across multiple services. For example. Let’s say you have a user, the authentication service require your username and password. An authorization service require your username and access rights, a location service might have your address and geolocation, Then you maybe a shipping service that also have the address. And you want your data to be consistent on all these services.
Another perspective from a testing point of view is that it is typically easier to setup partial environments like running only a few of the services needed. Which speed up testing significantly, but you need to be mind full of your “production like qualities” that you care for and you have in that setup. So I found myself more testing on various different setups depending on the kinds of tests I was running (not working with service testing at the moment).
Some other topics to discover is testing in production / chaos monkey / agent testing etc. Which to some degree is a more holistic approach and is a very potent complement to the more exhaustive testing on a service level.