[No Audio]
In this video we're going to review the project
structure that was created for us by the
Quickstart archetype in the previous
video and just have a bit of an overview
of it so we know what goes where.
So in the myapp generated Project you can
see here we have the src folder and directly
underneath the src folder we have two
subdirectories, we have main and test.
So in src, main, java, this is where
the production code for the application would live.
Src, main, resources would hold any class of
resources it needed to use in production and
as a sibling folder to that. In other
words, on the same level we have this test
subdirectory and again we have java underneath there.
So we've got src, main, java which is where
our production source code is going to live.
And then we have src, test, java which is
where our test source code is going to live.
And you'll notice as well IntelliJ
color codes these for us.
So you can see here we've got the blue
directory which means the production source code
folder. And here we can see we've got the
green directory which means test source folder.
Now it's important that we separate these two source
trees apart from each other, so the production source
code lives separately from the test source code.
This is so that it makes it easy to compile
and bundle the different source sets as is needed.
But also while we're on the subject of separation, we
also need to ensure that the junit dependency which
we've brought in here is a test scoped dependency.
So if we just put this in here
[No Audio]
and go for XML tag, we can see here we've got scope
and then we can just go down and insert test.
Now you won't see anything change here because this
is a list of the complete set of libraries this
project references, regardless of the class path type.
However, by putting this scope test tag in here, we're
ensuring that junit will only ever be used and
accessible to code, which is in this src, test, java
folder. In other words, it'll never be
bundled with our production applications.
It won't, for example, exist in a Webinf
Lib directory inside a wall file if we
were creating web applications to take one example.
So this scope test really means that it's
only ever used for the test source code,
and that's exactly what we want as well.
Similarly, when we introduce Mockito later in
the course, we'd also put this in
as a test scope dependency as well. And
finally, because junit depends on Hamcrest to be
able to function, then Hamcrest is also scoped as
a test dependencies, so it inherits the same scope
as the dependency that's pulling it in.
So while this stuff about dependency scopes might
not seem that interesting at this current time,
it's really important that you get the right
scope whenever be importing test libraries to make
sure that you don't accidentally include those test
libraries in your production source code. Anyway
that was a nice overview of the generated project
structure and now we've got a good idea where
we can find things so let's move forward with
this and start using JUnit in the next videos.