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!
"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.
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:
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.)
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.
Try a rapid pace of:
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:
In my idea, it all depends. Lot's of other factors come into the play:
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:
