Appendix D. Where Should I Go Now?

So where does the Newborn go from here? The net is vast and infinite.

— Motoko/2501 Ghost in the Shell (2005)

There is so much we have discussed in this book! So much, and still not enough. Every topic we have covered opens on to new subjects still to be discovered. Each thing we have learned steers us towards other things that we do not yet know about. The question "Where should I go now, after I have learned so much about unit tests?" does not have just one valid answer. Instead, there are thousands of them, depending on your requirements and likings. Below, you will find some hints concerning what topics to tackle next. The majority of them are strongly focused on developers’ tests (I hope you will follow this path!), but some are of a more general nature and aim at making you a better developer in a broader sense.

•It is essential that you build up your knowledge of testing tools. Scan the documentation of JUnit and Mockito, searching for things that this book does not cover (you will find some, for sure). Read the announcements of new versions, so you are up-to-date with the newer features they offer.

•Master the tools you use (IDE, build tools, command line), with regard to writing and executing tests.

•Take some time to learn other testing tools, especially if learning new languages. While it is still possible to use JUnit and Mockito with other JVM languages (e.g. Groovy or Scala), it might be beneficial to learn tools which have been designed using features offered by these languages. After reading this book you should have a very good understanding of unit tests in general, so you will be able to grab any new tool and use it properly.

•Start coding TDD if you have not yet done so. If possible, try to team up with some more advanced peers for pair programming. Also, there are some plugins for IDEs which aim at making it more fun to write tests - see if they help you.

•Mastering TDD and writing higher-level tests should lead you towards BDD ([north2006]). Very good, this is the right direction.

•This book has demonstrated in detail how to write unit tests; however, there is a mountain of things to learn when writing and testing whole applications. Reading [freeman2009] seems like the best possible way to dive into the world of testable software. Also, you should start writing integration and end-to-end tests. Which books you should read, and which tools you should look at, depends very much on the set of technologies you use, so it is hard to recommend anything here.

•If you happen to work a lot with legacy code then grab a copy of [feathers2004].

•Unit tests are really helpful, provided that you have a process for running them automatically. This brings us to the topic of build tools and continuous integration servers. If your team does not use them yet, then do make it happen. If your team is already there, then make continuous delivery your goal.

•Share your knowledge and experience (or lack thereof) with others. You can do it in various ways:

•Take part in some community events, especially code retreat meetings1. This is a GREAT way of honing your skills (and involves a lot of unit testing!). Other ideas - like doing code kata2 -

are also worth trying.

1See http://coderetreat.org/

2See http://en.wikipedia.org/wiki/Kata_%28programming%29

282

Appendix D. Where Should I Go Now?

•Share your code using sites like the GitHUB social coding platform (http://github.com).

•Ask for guidance/help/comments using sites like RefactorMyCode.com (http:// refactormycode.com/) or StackOverflow (http://stackoverflow.com).

•Involve yourself in some open-source project to collaborate with others on some cool features.

283

Bibliography

You cannot open a book without learning something.

— Confucius

Books

[feathers2004] Michael Feathers. "Working Effectively With Legacy Code", Prentice Hall, 2004

[fowler1999] Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, "Refactoring: Improving the Design of Existing Code", Addison-Wesley Professional, 1999

[freeman2009] Steve Freeman, Nat Pryce. "Growing Object-Oriented Software, Guided by Tests (Beck Signature)", Addison Wesley, 2009

[gof1994] The "Gang of Four": Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley, 1994

[goetz2006] Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea, "Java Concurrency in Practice", Addison-Wesley Professional, 2006.

[martin2008] Robert C. Martin. "Clean Code: A Handbook of Agile Software Craftsmanship", Prentice Hall, 2008

[meszaros2007] Gerard Meszaros, "xUnit Test Patterns, Refactoring Test Code", Addison Wesley, 2007

Documentation

[junitWebsite] JUnit project website, https://junit.org

[junitWiki] JUnit wiki, https://github.com/kentbeck/junit/wiki

[mockitoJavadocs] Mockito Javadocs, http://docs.mockito.googlecode.com/hg/latest/index.html

[mockitoDocumentation] Mockito documentation, http://docs.mockito.googlecode.com/hg/latest/org/ mockito/Mockito.html

[junitparamsJavadocs] JUnitParams Javadocs, http://junitparams.googlecode.com/hg/apidocs/index.html

[junitparamsDocumentation] JUnitParams documentation, http://code.google.com/p/junitparams/

[unitilsJavadocs] Unitils Javadocs, http://www.unitils.org/apidocs/index.html

[unitilsDocumentation] Unitils documentation, http://www.unitils.org/

[hamcrestDocumentation] Hamcrest documentation, http://code.google.com/p/hamcrest/

[festJavadocs] FEST Fluent Assertions Javadocs, http://fest.easytesting.org/assert/apidocs/index.html

[festDocumentation] FEST Fluent Assertions documentation, http://fest.codehaus.org/Fluent+Assertions +Module

284

Bibliography

[powermockJavacods] PowerMock Javadocs, http://powermock.googlecode.com/svn/docs/ [powermockDocumentation] PowerMock documentation, https://code.google.com/p/powermock/ [awaitilityWebsite] Awaitility project website, http://code.google.com/p/awaitility/ [easytestWebsite] EasyTest project website, https://github.com/EaseTech/easytest-core [pitWebsite] PIT project website, http://pitest.org

Articles

[beck2008] Kent Beck, Just Ship, Baby, http://www.threeriversinstitute.org/JustShip.html [bybro2003] Mattias Bybro, "A Mutation Testing Tool For Java Programs"

[carr2006] James Carr, TDD Anti-Patterns, http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/

[faber2008] Szczepan Faber, "Should I worry about the unexpected?", http://monkeyisland.pl/2008/07/12/ should-i-worry-about-the-unexpected/

[fowler2007] Martin Fowler, "Mocks Aren’t Stubs", http://martinfowler.com/articles/ mocksArentStubs.html

[freeman2004] Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes. "Mock Roles Not Object", http:// www.jmock.org/oopsla2004.pdf

[north2006] Dan North, Introducing BDD, http://dannorth.net/introducing-bdd/

[ma2005] Yu-seung Ma and Jeff Offutt and Yong Rae Kwon, "MuJava : An automated class mutation system."

[savoia2007] Alberto Savoia, How Much Unit Test Coverage Do You Need? - The Testivus Answer, http:// www.artima.com/weblogs/viewpost.jsp?thread=204677

[seradio167] Martin Lippert, Kent Beck, "Software Engineering Radio, Episode 167, The History of JUnit and the Future of Testing with Kent Beck"

285