Yes, when I have a large project in mind, I usually test certain assumptions first for "proof-of-principle," which I think are basically unit tests. Like when I wrote the SMB3 Map Editor, the first thing I tested was loading the tiles, the palettes, and the sprites, along with using the tile maps specified in the game data and the Win32 API (SetDIBitsToDevice() was the function to actually draw the bitmap data on the window) to display World 1 of the game on a window. With that, I learned how to do a very important part of the program I needed to write and I showed myself I could make it work, and I started a new project with that in mind. Despite that, it took 3 attempts total (each attempt representing a separate project) to finally succeed in making the SMB3 Map Editor work.
It also occurs in smaller programs, where they aren't functioning as suspected. I start to dig through the code for any possibly erroneous assumptions I may be making about how, say, a library function call works, and then I do unit tests surrounding things like that library function call to test my assumptions--almost always in a separate project devoted just to tests. I find out where my assumptions are erroneous and then correct them, which results in the program working after much testing and debugging.
_________________
"You have a responsibility to consider all sides of a problem and a responsibility to make a judgment and a responsibility to care for all involved." --Ian Danskin