Should developers work in sandboxes?

Question

If developers perform unit testing in their development environment before checking in to source control should that environment (including test failures) be shared?

Should all builds be public?

Answer 1

I think it´s impractical to make developer builds public. You do not want to bother your team members with every build failure (unit test failure) you encounter.

You are always in the process of creating a solution for some problem and chances are you won't get it right the first time so unit test failures will happen often. Especially if you take a test-driven approach to developing your code: writing your unit test first and implement functionality so it will not fail anymore.

Answer 2

Yes developers should work in sandboxes if possible. No builds should not all be public by default. TDD will lead to multiple failures and refinements to both tests and code. Sharing builds publically may be bothersome but certainly other developers should be able to see what someone is up to if they cared enough to go and look. They should be made public when asked to do so. If you are asking for proof that they tested something the running their unit tests after they check the code in should be proof enough.

Giving developers the environment, tools, and freedom to test changes liberaly will improve the stability and quality of your software. Testing theories and trouble shooting often require small incremental builds. If the sandbox is expensive they should be required to reserve time for using it. Giving each developer a private sandbox could result in their code branching for long periods of time. What is your motivation in asking this? If the developer is trying to hide something then get to the root cause of that issue. If you are trying to control costs then consider the reservation model.

Answer 3

What benefit do you see in this? In particular, it means everyone gets email about every picayune test failure by every developer.

This merely serves to distract everyone.

Avoid the temptation to do something just because it's possible to do; let your requirements drive your process. Don't create new process just because you can.

Answer 4

I think working in a sandbox is a good idea. It has saved me a few times. I usually have a few different virtual machines floating around that I use for development and if I mess it up real bad I don't have to wait for my machine to be rebuilt.

I don't think all test results from simple developer builds should be made public. I'm not really worried about hurting someone's feelings by having all their failures public necessarily but I worry that the information they provide isn't useful.

It would be interesting to investigate some type of system whereby the developer is required to submit passing test results when they checkin but I think even that would be pushing things. It may have the detrimental effect of hurting productivity. Developers have enough non-coding stuff to do already.

Answer 5

Children should play in sandboxes ;), software developers should play on their own PC and commit their code whenever they feel it meets a certain quality level. When everybody commits and updates small and tested pieces of code regularly then my experience is that no serious problems occur, only constructive feedback and sometimes somebody shouts something. Finally releasing the software to the public/customers is a different story. That takes extensive testing, writing release notes, updating manuals, marketing, etc.