What are common java web development practices?

Question

I'd like to learn more about/better understand common java web development practices of development groups that have at least two teams - web designers and web component developers. Particularly, I'm interested in understanding things like:

1. Assuming there is a code repository, do all teams checkout a local copy of all code? If yes, why would a web designer want/need access to back-end code, similarly why would a web component developer want/need access to front-end code?

2. How does each team-member, regardless of team, test their code - do they 'deploy' the code to their local workstation, an individual instance on a development box, or a consolidated dev box?

3. How is integration and testing done? For example, let's say a web designer creates a 'sign-up' form page and web component developer creates the back-end code to process and insert the data into the db - how would the front-end and back-end code be integrated and tested?

Any additional information that pertains to java web development practices of development groups that I have not specifically inquired about, but is relevant, please do share.

EDIT (FOLLOW-UP): I appreciate the answers, they've filled in most of the conceptual holes I had about java web development. However, I do have a couple of follow-up questions -

1. Testing, particularly automated testing are clearly important parts of java web development; but what constitutes a good "test"? For example, lets say a java back-end developer just put together code that accepts form data, validates it, and then inserts into/updates a database. What would be a good test in this scenario? Furthermore, how could this be "automated"?

2. Can someone expound on continuance integration - i.e. is their purpose to only compile all project code? Or is it to help in automated testing? From what I understand continuance integrations servers monitor repositories for commits, and upon commits checkout the newly modified code and compile the entire project; upon successful/failed compilation the user(s) are notified.

Answer 1

1. We always check out all the sourcecode we can get our hands on. Source code for external libraries, backend systems and the works. Reading code of backend systems makes it easier for frontend developers to understand what's going on. Backend developers sometimes read frontend code to see how things are actually being used. More code is a good thing. Maven also supports auto-downloading of source code, which is great.

2. We use maven, and I really recommend it in a team environment. We deploy locally, on team centralized test servers and common acceptance environments. The closer to "home" you can test things, the cheaper and more efficient.

3. We use selenium for a lot of testing that allows use to test "through the front" of a properly deployed webapp. Other than that, most of the integration tests that run parts of the stack run as regular junit tests within a maven profile.

Answer 2

How we do it on our team:

1. Yes. Each member checks out all code even though you are not working an all parts. You need to run the application on your local machine while you work to quickly view changes that you make. The front end guys need to run the backend code to see the front end effects.

2. During coding each member runs the code on their own machine. When it is checked in it is tested as a whole on a specially designated server.

3. Testing should be automated as much as possible. Each team member writes test code for their part of the code and that is also checked in. You can use a continuous integration server to run those tests automatically. But the initial test is actually done on the local machine. If I check out the code, then make a change to a backend class, I will run the code and make sure that it works on my machine, update whatever tests needs updating and commit my changes. The automated tests run on the server to ensure that the various commits all work well together.

I can't say if that is the best of best practice but it is practical practice for our very small team of only 4 devs.

Answer 3

In our team...

1. It is our pratice to usualy make a new branche in the repository for new developpments, and then merge them in the trunk to be tagged, when ready to be deployed in production. So we checkout all the branche we are working on. Also, using SVN, multiple coder can work on the same file as SVN do not lock the file and let you merge them after, but that's a relly rare case. Auto-merge won't always work and you'll have to do some "manual merging".

2. First tests are done localy, then deployed in a developpement environment, then acceptance environment. The code tested in the DEV and acceptance enviroment is builded by Luntbuild/ANT and delpoyed in our ApplicationServer via Jythons scripts. We never deploy or build manualy outside of the local environment. When possible, we ask other people of the team to test those deploy.

3. Cactus API let you "warp up" jUnit test for servlets/struts/web app. We do some stress test with JMeter, and Selenium (nice firefox plugin) for some other tests. You can also run coverage tools (like EMMA) that let you know what percentage of the code is covered by your jUnit/Cactus tests.

Answer 4

For the first question, you should generally be able to see the source code for each and every line in a stack trace (this also means that you use JDK's for development as Eclipse automatically attaches the src.zip file to the runtime libraries) even if it is outside of your own area of expertise.

So, check out all you can. It WILL help you some day - also coders tend to write better code and document it better if they know the whole team will always see it.

For development and deployment. You may do whatever you want to be able to develop and test your code, but any code going in production or outside the team MUST have been built by a machine (this ensures reproducibility). We use Hudson for this, but that is just an accident. The latest starter team licenses for Atlassian Bamboo might mean that we use that too.

Answer 5

1. That depends of yours project structure. Usually java webapp projects adhere to Maven project convention. If you have one project for web and backend functionalities all team mebmbers need to checkout sources, if structure is splitted into web and backend project every team can checkout only theirs projects.
   • Simple webapp maven project structure
   • Multi module maven project structure
2. If you use Maven it comes naturally to deploy application. Highly recomended is to use CI (continous integration) server like Hudson. Antoher very important aspect is to use appropriate set of plugins (maven or hudson one) like selenium tests or another web test framework.
3. Integration test are done by Maven/Hudson of course with a little help of plugins :). I've mentioned Selenium, that might be Canoo WebTest or other testing framework sometimes suitable for framework or technology you choose for development.

To sum up follow the Maven way.

Answer 6

Assuming there is a code repository, do all teams checkout a local copy of all code? If yes, why would a web designer want/need access to back-end code, similarly why would a web component developer want/need access to front-end code?

This depends on how big and how modular your project/build is. For big projects with big code base, using a modular approach and binary dependencies is a must. This will drastically improve local builds time. If I work on module A (that depends on B), I don't want to compile B during development cycles. This would slow me, this is annoying. I prefer to use a binary dependency on B (and if I need to, I can still checkout B and compile it locally).

How does each team-member, regardless of team, test their code - do they 'deploy' the code to their local workstation, an individual instance on a development box, or a consolidated dev box?

Use dedicated environments per developer for web severs, application servers, database instance (see Use one database instance per developer). Team members should be able to restart, redploy, whenever they want without disturbing others (even if I advocate minimizing the time spent "in container" during development, i.e. preferring unit tests in isolation). Thus, prefer the local workstation for everything that might need to be restarted: web server, application server, etc. Local deployment is also often easier. For the database, a remote database instance is fine in general (and might be better e.g. if you have a big oracle server). Use a consolidated dev box for the continuous integration process.

How is integration and testing done? For example, let's say a web designer creates a 'sign-up' form page and web component developer creates the back-end code to process and insert the data into the db - how would the front-end and back-end code be integrated and tested?

Test them separately first. Mock/Stub the back-end if required. Then test the whole. When doing integration or functional tests that interact with the database, a good practice is to always put the database in a known state before to run the test (see Good setup don't need cleanup!). DBUnit can help doing this. Cactus is another good tool for server side testing, e.g. integration testing. To run functional tests aka end-to-end testing, Selenium or WebDriver are good candidates. For acceptance testing (or BBD), I'm currently investigating Cucumber and I like it.