TDD Setup – Is Your Development Environment Correct?

continuous integrationenvironmenttdd

This is how my team has it's development environment set up:

  1. Each team member has a local development environment on their own computer, where they check out the code from a shared repository.

  2. Every developer work in their local development environment, once they finished writing the code they commit back.

  3. The code is then checked out to a staging/testing server with the same environment setup

  4. If everything is OK, it will be pushed to a production server.

We're trying to integrate unit testing and BDD (behavior driven development) into this setup and we'd like to use a continuous integration server (Jenkins) too.

My question is where should we install this and where should we test the code?

  1. Install the full testing stack for each developer: TDD tools + BDD tools + Jenkins?
  2. Install the test tools only on the staging/testing server and only test code here once each developer made his/her code commit?

How is your setup?

Best Answer

Installing a CI (Jenkins in your case) on every single workstation would be an overkill. This thing is pretty heavy! Common practice is to have it only on one server and make it check for modifications (commits) in the repository every X minutes (so it automatically builds) - or you can make a post-merge hook in your VCS to trigger a build.

What do you mean by testing tools? Every dev should be able to run unit/integration tests from his environment if that is what you are asking about. In fact it is a good practice to run tests before you commit (I know that the CI is there to check it anywhere but still I prefere not to crash the builds).

The setup at all the companies I worked was pretty similar:

  1. everyone has its own local dev env where he can run unit/integration tests if he wants to
  2. there is obviously a common VCS repository where we all commit
  3. there is a CI on a server somewhere polling for new commits from the VCS repo and if it finds one it starts a CI job building the whole project checking for any failures (build or test ones).
  4. we had a nightly build for each project which would build the application from the latest sources from the repository and deploy it to the server in the middle of the night when no one is using it.

You can go even further and try to adopt continuous deployment. We do not have that at my current job since the procedures of deploying the application are very corporation-like.

Nice things to have:

  • mails incoming after every build (saying it either succeeded or failed, always send a mail, if you want not to send one after a successful build it is a mistake since you don't know if the build was triggered or not)
  • a screen in a visible to all/most developers place with the current state of all your builds
Related Topic