StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>The problem I see with the first approach is that it would become difficult to extract those tests when you make a full build of the system</p> </blockquote> <p>You could always filter classes based on some naming convention like a special suffix or prefix when packaging (e.g. don't include <code>**/*Test.class</code> with Java). I don't really like this approach though, I find it messy and fragile. </p> <blockquote> <p>for the second, how would you test functionality that is only visible at the package level?</p> </blockquote> <p>Unless I'm missing something, I don't see the issue. You CAN have classes in the <strong>same package</strong> and have them living in <strong>different trees</strong>, e.g.:</p> <ul> <li><code>src/main/java</code> for application sources <ul> <li><code>src/main/java/foo/Bar.java</code> </li> </ul></li> <li><code>src/test/java</code> for tests sources <ul> <li><code>src/test/java/foo/BarTest.java</code></li> </ul></li> </ul> <p>Both <code>Bar.java</code> and <code>BarTest.java</code> are in the same <code>foo</code> package but in different directories. This is the approach I use.</p> <blockquote> <p>Is there a decent way to organize unit tests so that you can easily automate the build process and still access everything that needs to be tested?</p> </blockquote> <p>Well, as hinted, my <em>test sources</em> and <em>application sources</em> live in the <em>same</em> project but in <em>distinct</em> directory trees and this works really well for me. </p> <p>This is actually the default layout suggested by Maven (see the <a href="http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html" rel="nofollow noreferrer">Introduction to the Standard Directory Layout</a>). Whatever language you use, this might give you some ideas.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload