What's the decisive advantage of unit testing vs integration testing?
That's a false dichotomy.
Unit testing and integration testing serve two similar, but different purposes. The purpose of unit testing is to make sure your methods work. In practical terms, the unit tests make sure that the code fulfills the contract outlined by the unit tests. This is evident in the way that unit tests are designed: they specifically state what the code is supposed to do, and assert that the code does that.
Integration tests are different. Integration tests exercise the interaction between software components. You can have software components that pass all of their tests and still fail integration tests because they don't interact properly.
However, if there is a decisive advantage to unit tests, it is this: unit tests are much easier to set up, and require far less time and effort than integration tests. When used properly, unit tests encourage the development of "testable" code, which means the final result is going to be more reliable, easier to understand, and easier to maintain. Testable code has certain characteristics, like a coherent API, repeatable behavior, and it returns results that are easy to assert.
Integration tests are more difficult and more expensive, because you often need elaborate mocking, complex setup, and difficult assertions. At the highest level of system integration, imagine trying to simulate human interaction in a UI. Entire software systems are devoted to that sort of automation. And it is automation that we're after; human testing is not repeatable, and doesn't scale like automated testing does.
Finally, integration testing makes no guarantees about code coverage. How many combinations of code loops, conditions and branches are you testing with your integration tests? Do you really know? There are tools that you can use with unit tests and methods under test that will tell you how much code coverage you have, and what the cyclomatic complexity of your code is. But they only really work well at the method level, where unit tests live.
If your tests are changing every time you refactor, that's a different problem. Unit tests are supposed to be about documenting what your software does, proving that it does that, and then proving that it does that again when you refactor the underlying implementation. If your API changes, or you need your methods to change in accordance with a change in the system design, that's what is supposed to happen. If it's happening a lot, consider writing your tests first, before you write code. This will force you to think about the overall architecture, and allow you to write code with the API already established.
If you're spending a lot of time writing unit tests for trivial code like
public string SomeProperty { get; set; }
then you should reexamine your approach. Unit testing is supposed to test behavior, and there is no behavior in the line of code above. You have, however created a dependency in your code somewhere, since that property is almost certainly going to be referred to elsewhere in your code. Instead of doing that, consider writing methods that accept the needed property as a parameter:
public string SomeMethod(string someProperty);
Now your method doesn't have any dependencies on something outside of itself, and it is now more testable, since it is completely self-contained. Granted, you won't always be able to do this, but it does move your code in the direction of being more testable, and this time you're writing a unit test for actual behavior.