Fervent Coder

This came up in a discussion the other day so I thought I would share it. 

CREATE TABLE dbo.TestIdentity 

( 

      ID bigint identity(1,1) --primary key

      ,[Desc] char(20) 

)

INSERT INTO dbo.TestIdentity ([Desc]) values ('first')

INSERT INTO dbo.TestIdentity ([Desc]) values ('second')

SET IDENTITY_INSERT TestIdentity ON

--note the identities being inserted

INSERT INTO dbo.TestIdentity (ID,[Desc]) values (1200,'id-third')

INSERT INTO dbo.TestIdentity (ID,[Desc]) values (1,'id-fourth') -–this works until you set a unique constraint on the column.

SET IDENTITY_INSERT TestIdentity OFF

INSERT INTO dbo.TestIdentity ([Desc]) values ('third')

INSERT INTO dbo.TestIdentity ([Desc]) values ('forth')

SELECT * FROM dbo.TestIdentity

/*

 * You can only turn on IDENTITY_INSERT for one table per session so it's always a good idea to turn it off when you're done with it.

*/

DROP TABLE dbo.TestIdentity

Note that you can re-insert the same Id into an identity column unless it has a unique constraint on it, so limit it's use! Also note that when you turn off identity insert, it automatically re-seeds the identity at the next value after the HIGHEST value in the column.

Once you understand good design and the benefits, you don't go back.

One of our projects at work has nearly 800 tests in it (across 5 test projects).  The point isn't that we have 100% test coverage (because I doubt we do).  The point is that we know how a method behaves when sent empty and null values, and also for nearly every edge case in addition to the happy path. 

Most of these are 800 tests are logical unit tests. Some are system integration tests (parts of the system working with each other). And few are integration tests (tests that touch resources external to the code such as a database).

We also have an end-to-end project that has a number of black box tests in it that is not included in this number.

Oh, and the project in question is under 2,000 (LOC) lines of code.

This is by far the best designed and adaptable code that I have worked with since I started my career.  We are using NHibernate, IoC (using Windsor Castle Facility), Separation of Concerns, Generics, Interfaces, etc.

I know exactly what I have broken when I refactor the code within seconds.  It allows us to be easily adaptable to changes.  The reason I promote testing and all of the different ideas and components above is because I have been on both sides.  I have worked without any of this, including automated tests.  I know how fast I can respond to changes in my code and how fast I could have responded to changes in the past.  We can respond to changes so fast that the bearer of the work for every iteration is the testing.

In a [coding] world of Semper Gumby (Always Flexible), it's good to have code that is very respondent to change.

What is your success story?