elialbert/outside_in_testing.txt

## outside_in_testing.txt
The idea behind writing the code you want to see is to plan both your code and your tests as if you were a stakeholder / business owner, rather than a machine. Generally programmers who don't do this think of the task from a highlevel, then jump straight into the heart of the domain and start coding what they think it should be like. Then they jump out a level or two and write tests. But those tests are now only indirectly related to the high level view.
Outside in means writing the tests first, with the high level business requirements fresh in your mind, and then jumping in to write various pieces of the application incrementally, such that each peice of code is written in direct response with a failing test to make it pass.
The advantage here is that the final logic of the code itself will be more directly informed by the business logic, and will adhere more closely with the business requirements. There is a high chance that the code design will be better thought out and more clearly related to the business design. Less cruft, fewer revolution cycles.
I think the main advantage above all is that writing tests first forces the engineer to take their time and really think about the code design before jumping in. Frankly, I think if we as engineers could be trusted to do that every time, we wouldn't need TDD. But we really can't, and TDD makes it a necessity, AND you get automated tests out of the deal, so I'm a big fan.
An example: If I were to start with the logic code on a big project first, I might get sucked into fighting over a particular implementation detail, and I might spend all day perfecting it, only to discover the next day that it was not actually important to the project. It's easy to lose sight of business requirements when you're deep in code.
	The idea behind writing the code you want to see is to plan both your code and your tests as if you were a stakeholder / business owner, rather than a machine. Generally programmers who don't do this think of the task from a highlevel, then jump straight into the heart of the domain and start coding what they think it should be like. Then they jump out a level or two and write tests. But those tests are now only indirectly related to the high level view.
	Outside in means writing the tests first, with the high level business requirements fresh in your mind, and then jumping in to write various pieces of the application incrementally, such that each peice of code is written in direct response with a failing test to make it pass.
	The advantage here is that the final logic of the code itself will be more directly informed by the business logic, and will adhere more closely with the business requirements. There is a high chance that the code design will be better thought out and more clearly related to the business design. Less cruft, fewer revolution cycles.
	I think the main advantage above all is that writing tests first forces the engineer to take their time and really think about the code design before jumping in. Frankly, I think if we as engineers could be trusted to do that every time, we wouldn't need TDD. But we really can't, and TDD makes it a necessity, AND you get automated tests out of the deal, so I'm a big fan.
	An example: If I were to start with the logic code on a big project first, I might get sucked into fighting over a particular implementation detail, and I might spend all day perfecting it, only to discover the next day that it was not actually important to the project. It's easy to lose sight of business requirements when you're deep in code.