Software Development Cross Solution - Index of - Free

More documents

Recommendations

Info

white box testing was Below is a user story from BeatBox Pro. Your job was to write up three ideas for black or grey box tests, and descriptions of what you’d do to implement those tests. This is a black-box test. Also notice that we needed some JPEG resources to support the test. That’s OK; using sample input is fine. You should version-control those resources, though, for later reuse. These tests are a little more on the grey side. You need to know how BeatBox Pro should handle these conditions, and where exceptions would be sent if an error occurred. 242 Chapter 7 * Here are the three tests we came up with. It’s okay if you have three different ones... you’ll just have more ideas for actual tests. 1. Test for... sending a small JPEG to another user. Get two instances of BeatBox Pro running. On the first instance, click the Send Picture button. When the image selection dialog pops up, select SmallImage.jpg and click OK. Then check and make sure that the second BeatBox displays a Receive Image dialog box. Click OK to accept the image. Check that the image displays correctly. 2. Test for... sending an invalid JPEG to another user. Get two instances of BeatBox Pro running. On the first instance, click the Send Picture button. When the image selection dialog pops up, select InvalidImage.jpg and click OK. Check that BeatBox shows a dialog telling you that the image is invalid and can’t be sent. Confirm that the second BeatBox did not display a Receive Image dialog. Also make sure no exceptions were thrown from either instance. 3. Test for... losing connectivity while transferring an image. Start two instances of BeatBox Pro. On the first instance, click the Send Picture button. When the image selection dialog pops up, select GiantImage.jpg and click OK. Check that the second BeatBox shows a Receive Image dialog box and click OK. While this image is transferring (make the image several MB so it will take a while), kill the second BeatBox instance. Check that the first BeatBox displays a dialog saying the transfer failed and that no exceptions were thrown. Download at WoweBook.Com
White-box testing uses inside knowledge At the deepest levels of testing, you’ll find white box tests. This is where you know exactly what’s going on inside the code, and you do your best to make that code break. If you put aside the fact that you have to fix the code when it does break, white-box testing can actually be fun: it becomes a challenge to dig into code and generate problem situations that will cause errors and crashes. When doing white-box testing you should be familiar with the code you’re about to test. You still care about functionality, but you should also be thinking about the fact that method X is going to divide by one of the numbers you’re sending in... is that number being checked properly? With white-box testing you’re generally looking for: Testing all the different branches of code. With white-box testing you should be looking at all of your code. You can see all of the if/ elses and all the case and switch statements. What data do you need to send in to get the class you’re looking at to run each of those branches? Proper error handling. If you do feed invalid data into a method, are you getting the right error back? Is your code cleaning up after itself nicely by releasing resources like file handles, mutexes, or allocated memory? Working as documented. If the method claims it’s thread-safe, test the method from multiple threads If the documentation says you can pass null in as an argument to a method and you’ll then get back a certain set of values, is that what’s really going on? If a method claims you need a certain security role to call it, try the method with and without that role. Proper handling of resource constraints. If a method tries to grab resources—like memory, disk space, or a network connection—what does the code do if it can’t get the resource it needs? Are these problems handled gracefully? Can you write a test to force the code into one of those problematic conditions? White-box tests tend to be code-on-code Since white-box tests tend to get up close and personal with the code they’re trying to test, it’s common to see them written in code and run on a machine rather than exercised by a human. Let’s write some code-on-code tests now... Download at WoweBook.Com testing and continuous integration White-box testing TestGoodDBAccessor + getGC(gcId : int) :GiftCard + saveGC(card : GiftCard) :void Order DBAccessor + getGC(gcId : int) :GiftCard + saveGC(card : GiftCard) :void TestInsufficientDBAccessor + getGC(gcId : int) :GiftCard + saveGC(card : GiftCard) :void TestInvalidDBAccessor + getGC(gcId : int) :GiftCard + saveGC(card : GiftCard) :void MySqlDBAccessor + getGC(gcId : int) :GiftCard + saveGC(card : GiftCard) :void you are here 4 243 DB check balances, etc. saveOrder(...) insert into ... saveGC(...) update amnt ... Most code works great when things are going as expectedthe so-called “happy path”-but what about when things go off-track? Black-box testing looked at error messages, but what about what the code left around when things go wrong? That’s for whitebox testing to examine.
Page 2 and 3:
Download at WoweBook.Com
Page 4 and 5:
Praise for Head First Object-Orient
Page 6 and 7:
Other related books from O’Reilly
Page 8 and 9:
Head First Software Development by
Page 10 and 11:
the authors Author(s) of Head First
Page 12 and 13:
table of contents x 1 If The Goal g
Page 14 and 15:
table of contents xii 3 project pla
Page 16 and 17:
table of contents xiv 5 good-enough
Page 18 and 19:
table of contents xvi 6 / It buildi
Page 20 and 21:
table of contents xviii 8 Sometimes
Page 22 and 23:
table of contents xx 10 Think the n
Page 24 and 25:
table of contents xxii 12 You’ve
Page 26 and 27:
table of contents xxiv ii appendix
Page 28 and 29:
how to use this book Who is this bo
Page 30 and 31:
how to use this book xxviii intro W
Page 32 and 33:
how to use this book Here’s what
Page 34 and 35:
how to use this book Read Me This i
Page 36 and 37:
the review team The technical revie
Page 38 and 39:
safari books online Safari® Books
Page 40 and 41:
Tom’s Trails Tom’s Trails is go
Page 42 and 43:
the Big Bang approach The Big Bang
Page 44 and 45:
the Big Bang ends with a big mess B
Page 46 and 47:
great software development is... 8
Page 48 and 49:
delivering with iteration Getting t
Page 50 and 51:
an iteration delivers working softw
Page 52 and 53:
an iteration is a complete developm
Page 54 and 55:
uild a plan out of iterations and f
Page 56 and 57:
deciding on a iteration tempo for y
Page 58 and 59:
change happens The customer WILL ch
Page 60 and 61:
handle change with iteration Iterat
Page 62 and 63:
use the right process for you The r
Page 64 and 65:
CHAPTER 1 your software development
Page 66 and 67:
exercise solutions 28 Chapter 1 1 P
Page 68 and 69:
orion’s orbits Orion’s Orbits i
Page 70 and 71:
equirements start with customer ide
Page 72 and 73:
capturing what’s in your customer
Page 74 and 75:
getting more with role playing and
Page 76 and 77:
customer-oriented requirements Our
Page 78 and 79:
keep your customer in the loop Q: W
Page 80 and 81:
user stories capture what your soft
Page 82 and 83:
estimates come with assumptions 44
Page 84 and 85:
assumptions kill confidence in your
Page 86 and 87:
highlighting assumptions and obtain
Page 88 and 89:
assumptions are killed or become ri
Page 90 and 91:
use your customer effectively 52 Ch
Page 92 and 93:
keep estimates small A BIG user sto
Page 94 and 95:
aim for estimates you and your team
Page 96 and 97:
your estimates are your promise Q:
Page 98 and 99:
develop your estimates cyclically T
Page 100 and 101:
sum your estimates to find out your
Page 102 and 103:
when your project is too long 64 Ch
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
deliver what you can, when it’s n
Page 110 and 111:
priorities come from your customer
Page 112 and 113:
Title: Description: Est: Title: 15
Page 114 and 115:
factoring in team performance 76 Ch
Page 116 and 117:
uilding achievable milestones Work
Page 118 and 119:
your customer decides priority Titl
Page 120 and 121:
milestone = paid, iteration = on tr
Page 122 and 123:
continuously buildable and runnable
Page 124 and 125:
inging reality to your plan 86 Chap
Page 126 and 127:
velocity applies your real performa
Page 128 and 129:
from ideal to real estimates Progra
Page 130 and 131:
confidence comes at a price When is
Page 132 and 133:
iterations with velocity The maximu
Page 134 and 135:
eality means being honest Title: Es
Page 136 and 137:
eaking realistic but bad news Manag
Page 138 and 139:
introducing the big board The Big B
Page 140 and 141:
happiness is a project that can be
Page 142 and 143:
performance and burn down Work left
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
introducing iSwoon Introducing iSwo
Page 150 and 151:
eak up user stories into tasks Task
Page 152 and 153:
tasks have estimates Your task desc
Page 154 and 155:
tasks on your board Add your tasks
Page 156 and 157:
moving tasks to in progress Start w
Page 158 and 159:
multiple tasks at the same time Wha
Page 160 and 161:
keep communication flowing with dai
Page 162 and 163:
doing your first task Task 1: Creat
Page 164 and 165:
inging your design to life with a s
Page 166 and 167:
exercise solution The date is asked
Page 168 and 169:
monitoring your progress Standup me
Page 170 and 171:
updating your project board 132 Cha
Page 172 and 173:
updating your project board 134 Cha
Page 174 and 175:
into the second week Standup meetin
Page 176 and 177:
detecting problems with the design
Page 178 and 179:
surprises... 140 Chapter 4 We inter
Page 180 and 181:
dealing with unplanned tasks If the
Page 182 and 183:
velocity doesn’t account for surp
Page 184 and 185:
you know where you are We have a lo
Page 186 and 187:
meet velocity Head First: Welcome,
Page 188 and 189:
inging iSwoon under control iSwoon
Page 190 and 191:
detecting bad design ...you needed
Page 192 and 193:
design refactoring The Date class c
Page 194 and 195:
srp analysis Spotting multiple resp
Page 196 and 197:
single responsibility It makes sens
Page 198 and 199:
don’t repeat yourself Your design
Page 200 and 201:
efactoring iSwoon’s design A date
Page 202 and 203:
standup meeting The post-refactorin
Page 204 and 205:
unplanned work Unplanned tasks are
Page 206 and 207:
good-enough delivers “Good Enough
Page 208 and 209:
end of iteration board When everyth
Page 210 and 211:
exercises 172 Chapter 5 Take each o
Page 212 and 213:
exercise solutions Unplanned tasks
Page 214 and 215:
Page 216 and 217:
introducing beatbox pro You’ve go
Page 218 and 219:
digging into code Here’s the code
Page 220 and 221:
finish the story And now the GUI wo
Page 222 and 223:
merging changes And Bob does the sa
Page 224 and 225:
disaster recovery What went wrong?
Page 226 and 227:
version control in action Let’s s
Page 228 and 229:
1 2 creating a repository First set
Page 230 and 231: merging changes Most version contro
Page 232 and 233: identifying conflicts If your softw
Page 234 and 235: esolving conflicts Make these chang
Page 236 and 237: dealing with older code More iterat
Page 238 and 239: dealing with multiple releases We h
Page 240 and 241: viewing logs Good commit messages m
Page 242 and 243: tagging revisions (Emergency) stand
Page 244 and 245: anches and tags 1 Use the mkdir com
Page 246 and 247: working with branches Fixing Versio
Page 248 and 249: anches, tags, and subversion Q: I
Page 250 and 251: avoiding unnecessary branches When
Page 252 and 253: 214 Chapter 6 What version control
Page 254 and 255: CHAPTER 6 Development Techniques Us
Page 256 and 257: Download at WoweBook.Com
Page 258 and 259: uilding buildable software Develope
Page 260 and 261: introducing ant Ant: a build tool f
Page 262 and 263: more exercises 224 Chapter 6 ½ Are
Page 264 and 265: a full build script The javac task
Page 266 and 267: habits of good build scripts Good b
Page 268 and 269: even more build script tricks Good
Page 270 and 271: version control your build script Y
Page 272 and 273: CHAPTER 6 1/2 Development Technique
Page 274 and 275: it never rains but it pours Things
Page 276 and 277: lack box testing There are three wa
Page 278 and 279: grey box testing Grey-box testing g
Page 282 and 283: testing functionality BeatB These s
Page 284 and 285: you create tests test for establish
Page 286 and 287: one-click testing Testing EVERYTHIN
Page 288 and 289: making the most of a framework Auto
Page 290 and 291: continuous integration For you and
Page 292 and 293: setting up continuous integration A
Page 294 and 295: tests only cover what you tell them
Page 296 and 297: tested code is completed code } 258
Page 298 and 299: putting code to the test 260 Chapte
Page 300 and 301: 100% coverage All three of these te
Page 302 and 303: using a coverage report Testing all
Page 304 and 305: the cost of testing Q: How do cover
Page 306 and 307: is 100% coverage efficient? 268 Cha
Page 308 and 309: an environment for testing 270 Chap
Page 310 and 311: exercise solutions 272 Chapter 7 Te
Page 312 and 313: CHAPTER 7 your software development
Page 314 and 315: test before code Test FIRST, not la
Page 316 and 317: unit testing Your first test... The
Page 318 and 319: green means pass Get your tests to
Page 320 and 321: testing a user story’s functional
Page 322 and 323: implement a test in code import org
Page 324 and 325: drive your code with TDD In TDD, te
Page 326 and 327: task done when tests pass Completin
Page 328 and 329: first fail Red: write (failing) tes
Page 330 and 331:
keep it simple You can just make up
Page 332 and 333:
simple code is testable code Always
Page 334 and 335:
switching to test code with the str
Page 336 and 337:
where to place your test code Remem
Page 338 and 339:
etter code through testing Testing
Page 340 and 341:
tests = code and lots of it More te
Page 342 and 343:
mock objects We need lots of differ
Page 344 and 345:
using a mock object framework Mock
Page 346 and 347:
why mock objects? Q: These mock obj
Page 348 and 349:
all green, you’re done It’s not
Page 350 and 351:
test, red, code, green A day in the
Page 352 and 353:
Page 354 and 355:
Page 356 and 357:
esults from an iteration Your itera
Page 358 and 359:
daily standup meetings Standup Meet
Page 360 and 361:
urn-down analysis 322 Chapter 9 Bef
Page 362 and 363:
system testing System testing MUST
Page 364 and 365:
incorporating system testing System
Page 366 and 367:
issues with test iterations More it
Page 368 and 369:
enabling communication 330 Chapter
Page 370 and 371:
This is usually called acceptance t
Page 372 and 373:
filing and fixing a bug The life (a
Page 374 and 375:
ug trackers So you found a bug....
Page 376 and 377:
learn from your iteration But there
Page 378 and 379:
different project hurdles 340 Chapt
Page 380 and 381:
iteration reviews Time for the iter
Page 382 and 383:
other things to do A GENERAL priori
Page 384 and 385:
CHAPTER 9 346 Chapter 9 Tools for y
Page 386 and 387:
crossword solution 13 B 1 S Iterati
Page 388 and 389:
an iteration finishes with more tha
Page 390 and 391:
planning the next iteration You nee
Page 392 and 393:
uilding your board for the next ite
Page 394 and 395:
uilding your board for the next ite
Page 396 and 397:
factoring in real velocity Q: A tea
Page 398 and 399:
the customer still rules And it’s
Page 400 and 401:
it’s still software Someone else
Page 402 and 403:
integration tasks on your board Tit
Page 404 and 405:
integrating third-party code How yo
Page 406 and 407:
euse means trust too //... 368 Chap
Page 408 and 409:
when reuse lets you down Testing yo
Page 410 and 411:
trust no one Standup meeting 372 Ch
Page 412 and 413:
looking for problems in reused sour
Page 414 and 415:
finding problems in reused source c
Page 416 and 417:
your process deals with it You with
Page 418 and 419:
oken code happens � � � � Q
Page 420 and 421:
exercise solutions 2 R 1 R 3 E S P
Page 422 and 423:
At the end of the last chapter, thi
Page 424 and 425:
always communicate First, you’ve
Page 426 and 427:
prioritize what you do 388 Chapter
Page 428 and 429:
ump some things for later 390 Chapt
Page 430 and 431:
apply your process Priority one: ge
Page 432 and 433:
focus on functionality We could fix
Page 434 and 435:
test for bugs Figure out what funct
Page 436 and 437:
think about estimating Even though
Page 438 and 439:
spike tests Spike test to estimate
Page 440 and 441:
estimate what’s left What do the
Page 442 and 443:
factor in confidence Your team’s
Page 444 and 445:
always communicate Give your custom
Page 446 and 447:
apply other techniques Figure out w
Page 448 and 449:
successful deliveries matter Things
Page 450 and 451:
functionality wins most importantly
Page 452 and 453:
CHAPTER 11 414 Chapter 11 Tools for
Page 454 and 455:
crossword solution 10 F 15 H 5 P Bu
Page 456 and 457:
software process defined Pinning do
Page 458 and 459:
evaluate everything The big board 4
Page 460 and 461:
ensure changes improve things The b
Page 462 and 463:
formalize if necessary Formal attir
Page 464 and 465:
other resources Some additional res
Page 466 and 467:
CHAPTER 12 428 Chapter 12 Tools for
Page 468 and 469:
exercise solutions 4 S 11 P 14 A So
Page 470 and 471:
Page 472 and 473:
uml and class diagrams #1. UML clas
Page 474 and 475:
sequence diagrams #2. Sequence diag
Page 476 and 477:
user stories and use cases #3. User
Page 478 and 479:
system testing vs. unit testing #4.
Page 480 and 481:
Page 482 and 483:
CHAPTER 1 development techniques CH
Page 484 and 485:
development principles Deliver soft
Page 486 and 487:
Page 488 and 489:
the index building projects (contin
Page 490 and 491:
the index H Head First Java BeatBox
Page 492 and 493:
the index No Dumb Questions (contin
Page 494 and 495:
the index singularly focused 152 so
Page 496 and 497:
the index third-party code bugs in
show all

Software Development Cross Solution - Index of - Free

Create successful ePaper yourself

Delete template?

Save as template?