Software Development Cross Solution - Index of - Free

All of this...testing for
functionality, edge cases,
and hokey implementations,
adds up to a complete
testing approach.
Are you kidding me? Did you look at that code we
just wrote? We never once look at the expiration
date on a gift card, and we always set the balance
to 0. How can you call this better code?
Your code may be incomplete, but
it’s still in better shape.
Remember the second rule of test-driven development?
Rule #2: Implement the
SIMPLEST CODE POSSIBLE
to make your tests pass.
Even though not everything works, the code that we do have works,
is testable, and is slim and uncluttered. However, it’s pretty clear
that we still have lots of work left. The goal is getting everything else
working and keeping any additional code just as high-quality as what
you’ve got so far.
So once you get your basic tests, start thinking about what else you
need to test...which will motivate the next piece of functionality to
write code for. Sometimes it’s obvious what to test next, like adding a
test to deal with gift card balances. Other times, the user story might
detail additional functionality to work on. And once all that’s done,
think about things like testing for boundary conditions, passing in
invalid values, scalability tests, etc.
test-driven development
We’ve implemented the basic success-case test for processing
an order, but there are clearly problems with our implementation.
Write another test that finds one of those problems, and then write
code to get the test to pass.
Download at WoweBook.Com
you are here 4 301