When developing a new software module, I always insist on committing corresponding unit test modules before making any claim that the code might be ready for acceptance tests. It's not quite TDD (I have a problem with people committing code to a repository that doesn't compile), but I do try to write the tests at the same time as the implementation code.
This should be obvious to any experienced developer really, but as a freelancer it's even more important to be able to demonstrate to a client that a code module is actually fully implemented and fit for purpose. That doesn't mean you are making a claim to the code being bug-free (which would be a risky claim to make) but that the code does fundamentally do what is expected of it. As a freelancer, you absolutely need to do this in order to document due diligence on your part should things ever get nasty. If you don't and there is a problem, you could have enormous problems getting your invoices paid.
I once worked on a payroll application for a large European public institution in a team with several other freelancers and some permanent staff (who were in the minority at the time) when it came to the attention of our line manager that one of the other freelancers was spending more time surfing than coding. "My code is complete", he explained, "so it doesn't matter". Well, unfortunately for him, it did.
It turned out that his code only worked in one particular case (which was, ironically, the only case he had tested) but that in all other cases it crashed and burned. Of course, he hadn't implemented any unit tests or the like, which would have demonstrated that the code had been tested at least superficially. More unfortunately for him, this came to light during a demonstration for the client. As you can imagine, the line manager was livid and as the freelancer was unavailable to fix the mess he had left, it had to be done by one of the permies. Needless to say, the freelancer found his last invoices were not honoured by the client …