Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am a web and software developer involved in the creation of mobile apps. I am currently working on a project with a looming deadline. I am wondering if I should be committing code rapidly and large and testing later, or doing tiny commits and testing each one.

Thank you!

share|improve this question

marked as duplicate by gnat, Karl Bielefeldt, MichaelT, Bart van Ingen Schenau, GlenH7 Aug 24 '13 at 18:45

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

7  
Test early and often –  Dan Pichelman Aug 23 '13 at 19:28
8  
Pray tell, how do you think this will help with the deadline? –  delnan Aug 23 '13 at 19:44
7  
You mean to get more bogus code written faster - this will soon become a boomerang, believe me. –  Doc Brown Aug 23 '13 at 19:59
1  
Commit before test?? <Goes hunting for tar and feathers> –  Loren Pechtel Aug 24 '13 at 2:29
5  
@LorenPechtel: the first rule of version control is to never commit anything which will block your coworkers from working on their part of the application. This includes typically that the code compiles and that one runs a few tests. If that's enough before you commit is typically a decision which depends on the branch-/merge model one uses (for example, if you work with feature branches separated from the trunk). It also depends on if your coworkers are going to help you with reviewing and testing, for which they need your code. –  Doc Brown Aug 24 '13 at 7:29

6 Answers 6

up vote 34 down vote accepted

"We test later" always means "we test never", because there's never any time left to do it later. Whenever you have something changed that is worth testing, test it now.

You won't introduce fewer bugs just because you make more commits and fewer tests between the commits. Instead, you will pile bogus code on bogus code which, after n changes, becomes not n times hard to fix, but 2^n times, because you lose the feedback on which of your changes was the root cause for the bug.

share|improve this answer
    
2^n times? Why not n^2 times? –  Peter Mortensen Aug 24 '13 at 14:04
    
@PeterMortensen: because each bug can be in --two-- three states: (0, remain unfixed and visible), (1, not fixed but not visible somehow) (2, fixed), and each bug can manifest independently, so technically there are altogether --2^n-- no, 3^n states. –  rwong Aug 24 '13 at 15:39
1  
@PeterMortensen: I did not really have any "bug-math" in mind when I wrote that answer. –  Doc Brown Aug 24 '13 at 20:36

Should I be committing code quickly and testing later?

Once a functional piece of code is committed it is a good time to test. In another words, if committed code is testable, do your testing and don't postpone.

Postponing the testing (unit testing or manual one) on a committed code is a bit of an evil. That will potential to catch you up badly later on. As piling up on the commits without testing would not help to progress the project forward.

As mentioned, cutting the corners never ends to be productive. Just try not to skip steps and do your unit testing, before assuming that your task is done.

Related Stack Exchange question and blog post:

share|improve this answer

As others have mentioned, delaying testing often means that testing gets cut - even in the best case, testing far later from implementation leads to less efficient testing.

That said, there are benefits of checking in immediately. Quick check-ins reduce the risk and size of merge conflicts, both for you and your colleagues. If you have a build process that prevents you from breaking it (reject check-ins on build failure or unit test failure is the most common) then feel free to check in.

If you're going that route then once the code is in, then start on the unit tests. Do not delay them, do not get other things out of the way... don't cut corners.

I've seen this at multiple companies and works just fine as long as your team (or team lead) is disciplined enough.

(note: This is not the only way to successfully develop software. Tiny changes that are tested and checked in together will work. Test first development will work. What works best for you will vary significantly on who you are, what you're working on, etc.)

share|improve this answer

If you have a private development branch assigned just to you, then this isn't so bad. You'll need some way other than the checkin itself to indicate which checkins work properly and which don't, but you'll aboid losing work. I prefer to checkin when i get the next small something working, so that no checkin represents broken code.

On the other hand, if you share a branch with anyone else, then every partial checkin risks breaking other people's builds. That results in lots of other people trying to debug why something suddenly went wrong. This is a major time waste, duplicating effort of everyone who is debugging your broken stuff instead of building or fixing the stuff they are responsible for.

share|improve this answer
    
I am the only developer, but my next project will most likely involve a team. –  tjons Aug 24 '13 at 1:38

Try a rapid pace of:

  • Code some new functionality
  • Build locally
  • Test new code
  • Commit the change when it passes the tests.

I generally try to only commit working code. For new code I can be quite lax o the definition of working. For purpose of a commit, a method that returns a constant but has a TODO comment (preferably in a format my IDE recognizes) is considered working. A new method that generates a compile time error is definitely not ready for a commit.

Try for code you can complete in an hour or so. Cleanup as many of the TODO tags as you can before you move on to new code. Legitimate reasons to leave a TODO tag might include:

  • Necessary information is not available.
  • Other code is required to complete the item. This may be the next development priority.
share|improve this answer

In my idea, it all depends. Lot's of other factors come into the play:

  1. Does your team have a dedicated tester?
  2. Are you in a hurry of delivering a buggy demo to the client?
  3. Do you mind the first release not to have bugs?
  4. etc. etc.

I mean, while general guidelines exist, no prescription can be made for all teams around the globe.

Yes, of course testing and all concepts related to it would increase the quality of your product in a considerable way. Concepts like regression testing, unit testing, coded UI testing, integrity tests, security tests, performance tests, and all of'em make your software to become a first-class citizen to compete in the market. But that's only the academic view.

The practical view is however sometimes a little different. If you really need a demo, then write more code, and test less.

If you have a dedicated tester, then let him take the responsibility of testing. Collaborate, work together, but you spend more time developing and less time testing.

Also try to reuse tests through writing automated tests and getting far from manual testing.

As the last suggestion, I recommend that you reduce the features, because as a general rule:

Less robust features outweigh more buggy features.

share|improve this answer
    
Rephrase... FEWER , robust features, outweigh, NUMEROUS buggy features. –  Andyz Smith Aug 26 '13 at 13:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.