What should developers expect

Speaker's notes: It should take no more than 55 minutes to make it to this slide.

Speaker's notes:	It should take no more than 55 minutes to make it to this slide.

Time - you should save time in the long run

Speaker's notes:	Really, you should be spending this testing time already. If you are, and you are not using a framework, you will definitely save time by adopting a standard unit tset framework. If you aren't spending this time testing, then I fear for the users of your code. ;-) Seriously, you should expect to see an increase in the amount of time you spend before code gets to QA and the customer. Remember to increase your time estimates in this case, or you will be tempted to skip writing unit tests to meet deadlines. That's almost always a bad idea since bugs are more difficult to fix after they've shipped. One reason that many developers enjoy test first development is that it forces them to write the tests that they know they should be writing for their code. On the other hand, expect to see time spent on long term maintenance decrease.

Speaker's notes:

Really, you should be spending this testing time already. If you are, and you are not using a framework, you will definitely save time by adopting a standard unit tset framework. If you aren't spending this time testing, then I fear for the users of your code. ;-) Seriously, you should expect to see an increase in the amount of time you spend before code gets to QA and the customer. Remember to increase your time estimates in this case, or you will be tempted to skip writing unit tests to meet deadlines. That's almost always a bad idea since bugs are more difficult to fix after they've shipped. One reason that many developers enjoy test first development is that it forces them to write the tests that they know they should be writing for their code. On the other hand, expect to see time spent on long term maintenance decrease.

Amount of code - around 50% of code may be unit tests

Speaker's notes:	Thorough unit tests often comprise something near 50% of your total code produced. Simple code is often more than half unit tests. For example, we saw that the total_interest_continuously function (implemented in just a few lines) required a page of test code. Software with a more complex implementation but a small interface often has a unit test much smaller than the implementation itself, resulting in a ratio of test code to implementation that is smaller than 1:1.

Speaker's notes:

Thorough unit tests often comprise something near 50% of your total code produced. Simple code is often more than half unit tests. For example, we saw that the total_interest_continuously function (implemented in just a few lines) required a page of test code. Software with a more complex implementation but a small interface often has a unit test much smaller than the implementation itself, resulting in a ratio of test code to implementation that is smaller than 1:1.

Quality of code - immediate and long term improvement

Speaker's notes:	As I said, you'll probably be amazed at how many bugs you find when you first start unit testing. You'll see some immediate gains in code quality by fixing these bugs. You'll see another improvement later, in the long term, as you add tests for newly discovered bugs and prevent those bugs from creeping back into your code by rerunning your test suites as you code and before each release.

Difficulty - Small initial investment in learning a framework. Very simple in the long term.

Speaker's notes:	It may be extrememly difficult to add unit tests into an existing application. Expect to take a lot of time and to perform a lot of refactoring. Another alternative is to build regression tests for the application.

Focus - ongoing focus on making tests easy to write
Speaker's notes: Tests don't write themselves. You'll need to refactor the test "helpers" just like you refactor your code. There is no silver bullet.
Expense - Free! The frameworks are built into the language.