Simple cointoss game done with TDD

I made a simple cointoss game today using unittests.
I've managed to unittests all but one function, the fMain function.

The problem is that the fMain function depends on alot of functions(which are unittested by themselves) and also the random module to make random coin tosses, how could I unittests the fMain function in this code?

And also, are such simple programs meant to get this complicated and long when making them using unittests or is it just me overdoing it/polishing it too much?

The problem is that the fMain function depends on alot of functions(which are unittested by themselves) and also the random module to make random coin tosses, how could I unittests the fMain function in this code?

You need not "unit-testing" for full functionality of big and complex function. "unit-test" should test only some small unit of functionality.

If you want anyway to have some unit-test on this function, you can write the test with mocks which will check that fMain calls all dependent methods on the mocks (but not on real objects - since they are unit-tested separately as you told).

I'm sorry for I am not acquainted with instruments for unit-testing in python - I'm java developer - but the matter is similar. I believe mocks could be created with tools from standard library in Python:http://docs.python.org/dev/library/unittest.mock

And also, are such simple programs meant to get this complicated and long when making them using unittests or is it just me overdoing it/polishing it too much?

Well, unit-tests could often be bigger than source code, however in your case I fear here is some other problem. I fear your code is not well-designed to be testable and tests themselves are not written greatly. As a result you test your output too much but it is not really what is most important to test

We usually try to write separate test method for each method of program logic.

Aaah, thanks guys. I'll try to find me a couple of seeds that works with getting both players to win. And I might also try to mock the random.choice function. Already rewritten it abit so fMain is now called fsMain, so its now a function which returns a string, and that string is the winner of the match.

I'm not happy with the unittesting module because it takes up alot of horisontal space and it doesn't really give me any feedback on what went wrong, and ofc importing big modules is not a good thing in general.(unless I have to)

I'm not happy with the unittesting module because it is hard to use, or it could be that I don't understand it, or it could be that I started to use it before it provided tolerant comparisons causing us write a lot of code.