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.

Preface

I've worked at quite a few "flat" organizations in my time. Most of the version control policy/process has been "only commit after it's been tested". We were constantly committing at each place to "trunk" (cvs/svn).

The same was true with unit-testing - it's always been a "we need to do this" mentality but it never really materializes in a substantive form b/c there is no institutional knowledge base to do it - no mentorship.

Version Control

The emphasis for version control management at one place was a very strict protocol for commit messages (format & content). The other places let employees just do "whatever".

The branching, tagging, committing, rolling back, and merging aspect of things was always ill defined and almost never used. This sort of seems to leave the version control system in the position of being a fancy file-storage mechanism with a meta-data component that never really gets accessed/utilized. (The same was true for unit testing and committing code to the source tree)

Unit tests

It seems there's a prevailing "we must/should do this" mentality in most places I've worked. As a policy or standard operating procedure it never gets implemented because there seems to be a very ill-defined understanding about what that means, what is going to be tested, and how to do it.

Summary

It seems most places I've been to think version control and unit testing is "important" b/c the trendy trade journals say it is but, if there's very little mentorship to use these tools or any real business policies, then the full power of version control/unit testing is never really expressed. So grunts, like myself, never really have a complete understanding of the point beyond that "it's a good thing" and "we should do it".

Question

I was wondering if there are blogs, books, white-papers, or online journals about what one could call the business process or "standard operating procedures" or uses cases for version control and unit testing? I want to know more than the trade journals tell me and get serious about doing these things.

PS:

@Henrik Hansen had a great comment about the lack of definition for the question. I'm not interested in a specific unit-testing/versioning product or methodology (like, XP) - my interest is more about work-flow at the individual team/developer level than evangelism. This is more-or-less a by product of the management situation I've operated under more than a lack of reading software engineering books or magazines about development processes. A lot of what I've seen/read is more marketing oriented material than any specifically enumerated description of "well, this is how our shop operates".

share|improve this question
4  
I don't think this question is specific and it has been answered before. A quick glance at the list of related questions leads to several questions covering this rather broad question. –  Henrik Hansen Apr 6 '12 at 15:29
    
@Henrik Hansen my question is, great we have these tools and there's this hype to use them, so...how are people using them effectively? And are there publicly available, codified check lists , business process documents, or SOP documents that explicitly describe a use case for any of them. i can understand the ill defined question comment, i'm having some issues explicitly defining/stating a question. hope that helps. i'm not interested in a specific product or methodology (like, XP) - my interest is more about work-flow than evangelism. –  ct01 Apr 6 '12 at 15:42
1  
I see two questions. "How do we get over the "we should"-stages with unit testing?" and "How do we use our version control/tools to their fullest?" Of course, I can say this in hindsight after reading your question and being a third-party –  Henrik Hansen Apr 6 '12 at 16:56
add comment

closed as not constructive by gnat, Jarrod Roberson, tdammers, Walter, kevin cline Apr 6 '12 at 22:02

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

You get the understanding only by doing it. So the best way is to start doing it now, not next week or next month. There is always going to be a next milestone or an important feature, posing a good excuse to postpone writing the first unit tests or reading about new practices.

At this point, you need not worry about corporate policies. Just try the new thing out, see what works and what doesn't for you, get through the initial hurdles and - eventually - make it a routine practice for yourself. You will keep improving the more you practice it... Then you can start talking to others about it, evangelizing and raising awareness. Chances are, you will get a lot to say if and when the time comes to define standard procedures and the like...

I started writing unit tests on my own more than 10 years ago - noone on my team even heard about unit testing at that time. I just read about them on the net, thought "hey this looks cool, let's try it!", and so I did. My job was made easier by the fact that I was working on a greenfield project at the time, so practicing TDD was easy and it soon became an established practice for me. (It is much harder to write your first unit tests on legacy code, although it is still possible.) I have been writing unit tests ever since, and popularizing them wherever I worked. My current team is the first ever to actually have any unit tests implemented before I joined them (although just barely - they had started a couple of weeks prior to my arrival :-)

A couple of useful, practical resources, written by developers for developers:

share|improve this answer
add comment

Below are a couple of relevant posts from the StackOverflow network and (its "host") Joel Spolsky that you may find both helpful and interesting.

Unit Testing

Version Control

share|improve this answer
    
I'm familiar with Joel's work - I did find this on the blog link you posted, which sort of gets directly to the type content that I'm interested in: hginit.com –  ct01 Apr 6 '12 at 15:44
add comment

It seems most places I've been to think version control and unit testing is "important" b/c the trendy trade journals say it is but, if there's very little mentorship to use these tools or any real buisness policies, then the full power of version control/unit testing is never really expressed

There could be two reasons for this.

  1. Lack of knowledge and/or experience in architecting a good version control policy

  2. The "business side" demanding that more priority be given to completing the project then robust version control and quality tests.

I want to know more than the trade journals tell me and get serious about doing these things.

The only way to get serious about it is to take the first step and do it. Start a project (preferably open source) and apply version control and testing practices you know. As your project will be exposed to more eyes, and as your practices will be scrutinized, you'll only get better at it.

Just do it more and discuss it more. There is no other way -- no articles or blogs can tell you perfect ways to do these.

What you should look for is not a way to perfectly use version control, but the ability to find the right way to use it depending on the project at hand.

share|improve this answer
    
greengit: I've done a bit of opensource work in the past - it's always different in each project, as you've noted your response. Your comment sort of alludes to a thought that I've been bouncing around for sometime - which is these tools exist and their use is more of an institutional organic/iterative process - a what works for you - which sort of feeds back into my question about finding good documentation to start off, something to model from. I should probably just spend sometime reviewing big opensource efforts to see if they have documentation about work-flow and testing. –  ct01 Apr 6 '12 at 15:51
add comment

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