Software Development Cross Solution - Index of - Free

Good software is testable...
There are lots of things to think about when designing software: reusability, clean APIs,
design patterns, etc. Equally important is to think about your code’s testability. We’ve
talked about a few measures of testability like well-factored code and code coverage.
However, don’t forget that just because you have JUnit running on every commit that your
code isn’t guaranteed to be good.
There are a few testing bad habits you need to watch out for:
A whole-lotta-nuthin’
test-driven development
If you’re new to test driven development it’s very easy to write a whole lot of test code
but not really test anything. For example, you could write a test that places a Starbuzz
order but never checks the gift card value or receipt after the order is placed “Didn’t
throw an exception? Good to go.” That’s a lot like saying “it compiles—ship it.”
It’s still me...
In an overeager attempt to validate data it’s easy to go crazy testing fake data you fed
into the system initially and miss the actual code you need to test. For example, suppose
you write a test that checks that the gift card value and expiration date are correct when
you call getGC() ... on our TestDBAccessor. This is a simplistic example but if
you’re traversing a few layers of code with your test, it’s not too hard to forget that you
put the value you’re about to test in there in the first place.
Ghosts from the past
You need to be extremely careful that your system is in a known state every time your
automated tests kick off. If you don’t have an established pattern for how to write your
tests (like rolling back database transactions at the end of each test) it’s very easy to leave
scraps of test results laying around in the system. Even worse is writing other tests that
rely on these scraps being there. For example, imagine if our end-to-end testing placed
an order, and then a subsequent test used the same gift card to test the “insufficient
funds” test. What happens the second time this pair of tests execute? What if someone
just reruns the second test? Each test should execute from a known, restorable state.
There are a lot of ways to write bad tests—these are just a few of them. Pick
your search engine of choice and do a search for “TDD antipatterns” to find
a whole lot more. Don’t let the possibility of bad tests scare you off, though—
just like everything else, the more tests you write the better you’ll get at it!
Download at WoweBook.Com
you are here 4 309