JUnit测试的粒度问题

对于JUnit测试和TDD实践中有如下的疑问，请各位解惑：
JUnit测试的粒度如何把握？
简单的说是针对public的方法写测试就OK了呢？还是说要具体针对public方法中执行逻辑的每个步骤来写测试方法？
先说一下为什么会有这种困惑：
业务逻辑比较简单时，当然只针对Public方法的业务流程来设计案例，并只对public方法写test方法就好。
但最近做一个保险的项目，计算超复杂的那种，用户点一个Button后台要操作十几张表，数据Copy来Copy去
中间还有各种各样的计算，设计的业务Interface方法中接受User的输入，然后执行整个操作。
现在谈一下两种实现的方式：
1.按TDD的方式，先写测试代码，再写实现代码，实现过程不断重构(未完整了解过TDD，只是皮毛，如有误解见谅)
这种方式实现起来很有难度。首先测试代码的覆盖度很难保证：当复杂的业务逻辑揉在一个方法中(即使重构拆成若干小方法)，流程分支成幂增长，很难一开始就把所有的情形都考虑清楚，即使都考虑到了，写出来的TestCase也可能是超复杂的，反而会成为一种负担。
另外，这样来做实际上也就相当于大块大块的Coding,然后测试，偏离了TDD的本意，Coding过程中没办法保证做的每一步都是正确的，而是将这个测试推迟到完成了整个实现之后。
2.对整个业务逻辑的实现大致上先分为几个步骤，每个步骤的实现可以放在protected方法中以便测试，然后再针对每一步来实践TDD，这样没有上述的两个问题，而且最终程序员对自己代码的信心会大增。但这样来做也有一些问题。
首先，每一步骤的方法都是protected才能保证测试，这样破坏了封装
其次，测试代码是[b]针对接口实现的过程[/b]来写的，而不是[b]针对接口的功能[/b]，所以测试代码可能会很脆弱，实现过程稍作变化测试代码也可能要做修改

所以，最根本的问题也就是单元测试是应该针对接口实现的过程还是接口的功能？