Usually when talking about coding standards we refer to the code of the program itself, but what about the unit tests? Are there certain coding standards guidelines that are unique to unit tests? What are they?
Unit Testing – Coding Standards for Unit Tests
coding-standardsunit testing
Related Solutions
In my experience the main things I'd look for would be:
Table and column naming - look at whether you use ID, Reference or Number for ID type columns, singular or plurals for names (plurals being common for table names - e.g. THINGS, singular for column names - e.g. THING_ID). For me the most important things here are consistency which avoids people wasting time (for instance you don't run into typos where someone has put THING as a table name because you just know intuitively that table names are never singular).
All creates should include a drop (conditional on the object existing) as part of their file. You might also want to include grant permissions, up to you.
Selects, updates, inserts and deletes should be laid out one column name, one table name and one where clause / order by clause per line so they can be easily commented out one at a time during debugging.
Prefix for object types particularly where they might be confused (so v for view being the most important). Not sure if it still applies but it used to be inefficient for stored procedures other than system procedures to begin sp_. Probably best practice to differentiate them anyway usp_ was what I've used most recently.
A standard indicating how the name of a trigger should include whether it's for update/insert/delete and the table it applies to. I have no preferred standard but this is critical information and must be easy to find.
Standard for ownership of objects in earlier versions of SQL Server or the schema it should exist in for 2005 and later. It's your call what it is but you should never be guessing who owns something/where it lives) and where possible the schema/owner should be included in the CREATE scripts to minimise the possibility of it being created wrongly.
An indicator that anyone using SELECT * will be made to drink a pint of their own urine.
Unless there is a really, really good reason (which does not include laziness on your part), have, enforce and maintain primary key / foreign key relationships from the start. This is after all a relational database not a flat file and orphaned records are going to make your support life hell at some point. Also please be aware that if you don't do it now I can promise you you'll never manage to get it implemented after the event because it's 10 times the work once you have data (which will be a bit screwed because you never enforced the relationships properly).
I'm sure I've missed something but for me they're the ones that actually offer real benefit in a decent number of situations.
But as with all standards, less is more. The longer your coding standards, the less likely people are to read and use them. Once you get past a couple of well spaced pages start looking to drop the stuff that isn't really making a practical difference in the real world because you're just reducing the chance of people doing any of it.
EDIT: two corrections - including schemas in the ownership section, removing an erroneous tip about count(*) - see comments below.
A co-worker and I had a similar problem on our team when we first joined (I joined the team first, he joined about a year later). There were no real code standards. We're a MS shop, and even the MS coding standards weren't used. We decided to lead by example. We sat down together and drafted a document that had all of our standards: IDE standards, naming standards, everything we could think of. Then he and I agreed to follow the standard explicitly. I sent an email to the team (from the both of us), and notified them that we had found a lack and we were going to address the lack with our document. We invited critique, ideas, comments, opinions. We received very little in the manner of feedback and only a little push back. He and I immediately started using the standards, and as we brought junior developers onto our projects we introduced them to the standard and they began using it. We have a few leads who were reluctant at first but have slowly begun using the standard for a great many things.
We found that many of the junior developers had recognized the same problem but were waiting for someone else to step up and make the decision. Once there was a plan to follow, many were eager to adopt it. The tough nuts to crack are the ones who refuse to code by any other means, and they'll usually code themselves out of the picture in the long run.
If you want standards, blaze the path. Come up with a suggested list of standards you think would benefit your team. Submit it to peers and leads for feedback. I'm sure other people on your team have similar ideas, but they probably lack the gumption to do anything about it. As Gandhi said, "You must be the change you wish to see in the world."
Best Answer
Off the top of my head, I can think of three differences in coding style for test code.
In naming test methods, I follow the pattern of
shouldDoSomethingWhenSomeConditionHolds
.Inside the test, it is customary to follow the following spacing pattern:
Some insist on only one assertion per test, but this is far from universal.
The DRY (Don't Repeat Yourself) is less of a consideration in test code than in production code. While some repeated code should be placed in a setUp method or a testUtils class, striving for zero repetition in test code will lead to tightly coupled and inflexible tests, which discourages refactoring.