|
===Code visibility===
{{Main|Unit testing#Code visibility}}
Test code needs access to the code it is testing, but testing should not compromise normal design goals such as [[information hiding]], encapsulation and the [[separation of concerns]]. Therefore, unit test code is usually located in the same project or [[Module (programming)|module]] as the code being tested.
In test-driven development, writing tests before implementation raises questions about testing [[access modifiers|private methods]] versus testing only through [[Interface (computing)|public interfaces]]. This choice affects the design of both test code and production code.
In [[object oriented design]] this still does not provide access to private data and methods. Therefore, extra work may be necessary for unit tests. In [[Java (programming language)|Java]] and other languages, a developer can use [[Reflection (computer science)|reflection]] to access private fields and methods.<ref>{{cite web
|title=Subverting Java Access Protection for Unit Testing
|url=http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html
|last=Burton
|first=Ross
|date=2003-11-12
|publisher=O'Reilly Media, Inc.
|access-date=2009-08-12
}}</ref> Alternatively, an [[inner class]] can be used to hold the unit tests so they have visibility of the enclosing class's members and attributes. In the [[.NET Framework]] and some other programming languages, [[partial class]]es may be used to expose private methods and data for the tests to access.
It is important that such testing hacks do not remain in the production code. In [[C (programming language)|C]] and other languages, [[Directive (programming)|compiler directives]] such as <code>#if DEBUG ... #endif</code> can be placed around such additional classes and indeed all other test-related code to prevent them being compiled into the released code. This means the released code is not exactly the same as what was unit tested. The regular running of fewer but more comprehensive, end-to-end, integration tests on the final release build can ensure (among other things) that no production code exists that subtly relies on aspects of the test harness.
There is some debate among practitioners of TDD, documented in their blogs and other writings, as to whether it is wise to test private methods and data anyway. Some argue that private members are a mere implementation detail that may change, and should be allowed to do so without breaking numbers of tests. Thus it should be sufficient to test any class through its public interface or through its subclass interface, which some languages call the "protected" interface.<ref>{{cite web | url=https://www.python.org/dev/peps/pep-0008/ |title=PEP 8 -- Style Guide for Python Code |last1=van Rossum |first1=Guido |last2=Warsaw |first2=Barry |date=5 July 2001 |publisher=Python Software Foundation |access-date=6 May 2012}}</ref> Others say that crucial aspects of functionality may be implemented in private methods and testing them directly offers advantage of smaller and more direct unit tests.<ref>{{cite web
|url=http://blogs.msdn.com/jamesnewkirk/archive/2004/06/07/150361.aspx
|title=Testing Private Methods/Member Variables - Should you or shouldn't you
|last=Newkirk
|first=James
|date=7 June 2004
|publisher=Microsoft Corporation
|access-date=2009-08-12}}</ref><ref>{{cite web
|url=http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx
|title=How to Test Private and Protected methods in .NET
|last=Stall
|first=Tim
|date=1 Mar 2005
|publisher=CodeProject
|access-date=2009-08-12}}</ref>
===Fakes, mocks and integration tests===
| 