Working on Java projects, it is widely accepted that you should use a standard project layout. That is the standard template you find on many open source projects, i.e.
src/main/java
src/main/sass
src/main/test
src/main/resources
src/anotherModule/kotlin
Now, it is assumed that all tests fall under src/main/test. I have seen this everywhere.
Now suppose you want to separate unit from integration tests so that they will not run together in CI. Is there any widely accepted convention about project layouts for integration and/or automated E2E tests?
In general, is it correct to state that I should plan to store tests so that all those under the same folder will run in the same test execution? That means if I have multiple suites, each should have its own root folder. And again, is there any known and accepted convention that integrates with popular build tools and makes testing experience seamless?
I couldn't quickly identify any in most popular open source frameworks.
Related
I'm very much new to JUnit. We want to integrate JUnit into our old and big Enterprise Java application(which has many projects associated with it) developed long back.We want to do it without touching java files and on framework level. Is it possible? If yes, please share me the links or information on how to do it?
I can't comment (yet) so here is my recommendation as an answer:
"Working Effectively with Legacy Code" by Michael Feathers covers all scenarios of testing / maintaining etc. of old, huge applications in a very readable way.
Why would you touch existing Java files for writing unit tests ( if you are ready to leave non-testable classes in your source as they are) ?
Isn't integrate JUnit means writing unit tests for existing classes using JUnit ( for which unit tests have not been written so far) OR is there any other meaning you intend too?.
We keep test classes written using JUnit in a separate source-folder so those don't mess with your existing code.
I don't see any concern here. Just add JUnit jar into your project's build path ( by including jar OR by adding maven dependency OR by adding Gradle dependency ) and start writing unit tests for your testable classes and you are done with your integration.
You might choose to not include source-folder-for-tests into your deployment build.
Sometimes in your old code, some classes might not be testable so you will have to tweak those a little if wish to cover those too.
Hope it helps !!
I'm a CS master student. Throughout my studies I coded many course projects in Java. Soon I will graduate. When I explore some github projects I often find people organize their projects as /main and /test. I have never organized it in such a way, i.e. I always have my source code files without any test directories. I think that folder often contains what I think is called 'test cases' or so.
Since I will find a job soon, then I would like to learn about production-quality code.
My questions:
Why people often have that folder? What does it contain?
Can you provide me with a link to a good tutorial about the practice of testing in java? i.e how to do it? In a nutshell I wanna understand the idea of that /tests/ folder.
I often find people organize their projects as /main and /test
This is a matter of taste. Not 100% sure but at least maven projects have such organization.
From Maven: Introduction to the Standard Directory Layout, this would be the project layout:
src
main
java <-- your Java source code
resources
filters
config
scripts
webapp
test
java <-- your unit tests for Java
resources
filters
it
assembly
site
Why people often have that folder? What does it contain?
Usually, people write test cases to cover the code and check if the code works as expected. This is known as Code Coverage. Code coverage also serves as regression tests in case somebody makes changes in the code for enhancements like code refactoring.
The test cases you will find them usually are for Unit Testing. Depending on the type of the project, you could also find Integration Tests.
There is also Test Driven Development, or TDD, which is a practice whose basis is writing the test cases before writing the real code.
Can you provide me with a link to a good tutorial about the practice of testing in java?
This is off topic for the site. There are plenty tutorials on the net about this.
I don't have a separate folder for mine but usually people keep their Unit Tests in that folder. A unit test generally sets up "fake" data to test a given class so that a developer can easily debug any issues.
The reason people provide a /test folder is to contain unit test for their project.
There are really many ways of testing Java but JUnit is a very commonly used method of testing.
It is a good practice to write tests for your code. Begin with writing Unit Tests. I found this tutorial very useful. Writing test ensures that your code behaves as expected , corner cases are tested and adding new code in the future does not break existing functionality.
There are also mocking frameworks like JMock and Mockito that make writing stubs and drivers for your methods easy.
What is even more interesting is people prefer writing tests before they write the actual implementation. This approach is called Test Driven Development or Extreme Programming. Writing tests first ensure one already has a prep code or pseudo code for the methods in mind.
I'm working on a project with a maven structure and I want to begin doing some extended tests, but I'll need to a large amount of resources do to so. Any recommendations where I should place these resources? Should they go into 'src/main/test/resources' or be pulled from a different repo or something else?
Recapping your question
Any recommendations where I should place these resources? [...]
I'm aware that I can place them in 'src/main/test/resources' [...]
I'm thinking more of resources for integration tests. Developers won't necessarily want to pull a 100's of megs of resources from version control for tests they likely won't run.
Answer
You might change to a multi-module project layout, something like:
multi-module project
|
|
+---+-----------------+
| |
source and unit test integration test
prj prj
then your developers could pull only source and unit test prj.
Clearly integration test prj should have a compile scoped dependency on source and unit test prj.
Maven has an answer for you...
If you include the resources inside the 'src/main/test/resources' (that's correct)...
Remember that running an install in the final jar the tests will be excluded, and yes! The resources are excluded too...
Moreover you could skipping tests (also the compilation) to improve compilation performance...
(more info at: http://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html)
I hope this helps you...
UPDATE:
also give a look at "How can you display the Maven dependency tree for the *plugins* in your project?"
We should think about the reasons for excluding resources from the environment of the developer. I just answer your question telling the common practice of handling situations like yours by Maven...
If as you say it is actually a problem for you, it may be an idea, for example, to separate all the tests and resources inside another moduel...including that in your parent pom...
Or maybe to define a profile (integration test) which will contains largely of test resources, and a profile (Developing test) that will only lead tests useful to the individual developer ...
I personally think that unless there are special reasons (critical), beyond simply the amount of mega occupying test, you can safely proceed with all the resources in the test package...
You should run this kind of large integration tests on a CI server, not on developer machines.
It's good practice to run long-running integration tests on a different machine to reduce the dev-test cycle time. You wouldn't want to run that in your normal builds anyway, make a profile and run it on CI.
I think this is a long shot, but...
We have such project structure:
common-library
- denmark
- application
- france
- application
- application-xxxxxx
- application
- integration-tests
Each application has different configuration, translations, different package names and so on, but in all they are almost the same. They have the same features, same user interface etc.
Only one of our applications is now tested with integration tests with Robotium. Is there a way to "share" same integration tests for other applications?
It would be perfect to have "common tests" and custom/specific tests for each application. Is it at all possible?
We're using maven and Jenkins for our needs.
Any other approaches or suggestions are welcome.
well, assuming you need to maintain one set of integration tests only, I would go in direction of having:
separate maven module holding integration tests only
and in it I'd introduce multiple maven profiles, where each one would have specified maven dependency on one of the modules to be tested only
build can later switch between the profiles to activate the particular build only
As some notes on integration testing options say (http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing) and I believe it would affect this approach as well:
The disadvantage of doing it this way is that it tends to separate the integration tests from the code they're attempting to test. As a result, you may find that no one "owns" the integration tests; typically you'll have some one person whose job it is to analyze the integration tests and find bugs. QA is hard, but it's even harder when it's unclear who "owns" test failures.
Another problem could be if you run your builds including integration tests (via Jenkins) on code change automatically. Module dependencies would not launch your integration tests automatically. Rather you might need to define one Jenkins job per profile and define the correct jobs sequence manually.
E.g.: If Jenkins built denmark app => build integration, with profile denmark, ...
We've just started looking at using JBehave for acceptance tests and I was wondering how people that are using it are organising the writing of stories and the storage of story files. It's just development that are working on them at the moment so we have the story files stored in the resources folder alongside the Java code to implement them.
I guess my actual question is how and where are you storing your story files and how does this work with the product owner or QA writing stories?
#MrWiggles
as t0rx told you are lucky to have QA to write stories/scenarios. coming to your question:Behaviour-Driven Development encourages you to start defining the stories via scenarios that express the desired behavior in a textual format.
JBehave Stories you can run by configuring in Maven (pom.xml).
You can make a folder for storing your story files in your package structure, like below:
Your_Project
|
|
|--Source_Code
|
|--Stories
|
|--Testing
|
*pom.xml
By configuring your stories in maven, every time you build project it will give result with succeeded and failed stories/scenarios results.
QA will update the scenarios in the folder Stories, and the developer will implement the scenarios step by step by omitting existing steps (which are already developed and came in other scenarios).
QA simply run the scenario/story and he will find out the result in a textual (understandable) format.
Like below:
Behaviour-Driven Development in test levels.
Some of the JBehave features concentrate on easy organizing.
Annotation-based configuration and Steps class specifications
Dependency Injection support allowing both configuration and Steps instances composed via your favourite container (Guice, PicoContainer, Spring).
Extensible story reporting: outputs stories executed in different human-readable file-based formats (HTML, TXT, XML). Fully style-able view.
Auto-generation of pending steps so the build is not broken by a missing step, but has option to configure breaking build for pending steps.
Localisation of user stories, allowing them to be written in any language.
IDE integration: stories can be run as JUnit tests or other annotation-based unit test frameworks, providing easy integration with your favourite IDE.
Ant integration: allows stories to be run via Ant task
Maven integration: allows stories to be run via Maven plugin at given build phase
If you are lucky enough to have the product owner or QA writing stories then you probably want them in a specific area of your source code repository so you can control access independently from your main source (and also give you more flexibility with when CI builds are triggered if you're doing that).
You'll likely find a lot of back-and-forth to minimise the number of new steps the devs have to write (i.e. stop them using ten different ways to write the same step), so will also need to run with pending steps not failuring the scenario (which is the default out of the box).
An alternative approach is that QA/product owner send scenarios to the devs who then cleanse them before adding to source control, but this puts effort back on the devs.