Unit testing is not widely used in embedded software, but it should be. In my experience the best way to learn is to start writing some unit tests right now.
I think a significant problem is that embedded developers often have a different background than other software developers which is more focused on the hardware. Also, the major embedded publications tend to focus on the hardware as well. As a result, many embedded developers just don't get exposed to the ideas circulating in the greater software development community.
I've managed to make a career developing software and firmware for embedded systems. For the first 10 years of that career, however, I managed to avoid unit testing altogether.
That seems mind-blowing for me now, given how critical unit testing is to my current development process.
When I started developing software, I hadn't even heard of unit testing. I certainly didn't learn about it when I was getting my computer engineering degree -- It's unfortunate that in school I actually didn't learn that much about real software development in general. Classes and objects? Pointers and references? Even linked lists? Sure. But how to a create a real application, or even use design patterns? Nope.
Later, I continued to avoid exposure to it. I went to the Embedded Systems Conference (ESC) at least a couple of times and read trade publications. Looking back at ESC conference schedules, I see that James Grenning was talking about it but somehow I missed this and its revolutionary importance.
My first experience writing unit tests was when I worked on a portion of a C# application where my co-workers (application developer-types) had created unit tests. This particular application talked to a database, but mocks had been created so that a real database wasn't needed. All tests could be run by setting up some test data in a mocked database.
My task was to add to the existing functionality for which unit tests had already been implemented. Wow! The existing tests told me exactly how the system was supposed to behave under all conditions. I could make my changes, run those tests and confirm that the existing functionality was unaffected! And... by adding my own new tests, I could confirm that the new behavior was correct as well!
This was enlightening for me. These tests made it easy to prove that the system was working correctly, without running the full application and without requiring a database.
When I did some work on an Android project, I figured I would try some test-driven development. It went well. One of the things that makes the barrier to entry so low in C# or Android development is that the unit test tools are built right in to the environment. In Visual Studio or Android Developer Tools you just write some tests and click a button to run. It's extremely convenient for getting started.
Having seen the one true way and the usefulness of unit testing, I started using it in embedded development. One of the primary hurdles is setting up a framework (psst... try Ceedling) but once you set it up, you can just start cranking out tests. The more you do it, the easier it'll be and the more useful you'll find it.
One of the things you'll discover is how to separate the hardware interfaces from the software so that your tests can run without hardware. This has the consequence of promoting good software architecture as well as testability.
It took me a long time to get here, but there's no going back now. Unit testing is now the basis for my entire software development process. If you haven't yet seen the light, you should try unit testing now too.