Editing Code refactoring (section)

==Testing==
Automatic [[unit testing|unit tests]] should be set up before refactoring to ensure routines still behave as expected.<ref>{{Cite book |title=Refactoring : improving the design of existing code |last=Fowler |first=Martin |date=1999 |publisher=Addison-Wesley |isbn=978-0201485677 |location=Reading, MA |oclc=41017370 |url=https://archive.org/details/isbn_9780201485677 }}</ref> Unit tests can bring stability to even large refactors when performed with a single [[Atomic commit#Revision control|atomic commit]]. A common strategy to allow safe and atomic refactors spanning multiple projects is to store all projects in a single [[repository (version control)|repository]], known as [[monorepo]].<ref>{{cite book |last1=Smart |first1=John Ferguson |title=Java Power Tools |date=2008 |publisher="O'Reilly Media, Inc." |isbn=9781491954546 |page=301 |url=https://books.google.com/books?id=kE0UDQAAQBAJ&q=visual+sourcesafe+atomic+commit&pg=PA301 |access-date=26 July 2018 |language=en}}</ref>

With unit testing in place, refactoring is then an iterative cycle of making a small [[program transformation]], testing it to ensure correctness, and making another small transformation. If at any point a test fails, the last small change is undone and repeated in a different way. Through many small steps the program moves from where it was to where you want it to be. For this very iterative process to be practical, the tests must run very quickly, or the programmer would have to spend a large fraction of their time waiting for the tests to finish. Proponents of [[extreme programming]] and other [[agile software development]] describe this activity as an integral part of the [[software development process|software development cycle]].