Monday, February 11, 2008
Describing the rhythm of the TDD cycle
TDD
Monday, February 11, 2008 11:17:18 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 

Test Driven Developer


Assert.AreEqual(13, stripes);
Assert.AreEqual(50, stars);
see
ms like enough tests to me...

NOT!

Welcome to Test Driven Developer! This site is dedicated to those who understand the benefits of test-first development, and the advancement of the practice.

  It is sometimes hard to convince traditionally trained developers that it is better to write a test first, before writing the code. In Test Driven Development, we always write a test first before writing the code.

Many developers are hard to convince to use this methodology. It is very often difficult for a developer to understand completely what the code needs to do. Yet - they want to proceed to write it anyway? It's kind of a flaw in the thinking process.

Lucky that you are smart enough to know that there's a better way..

TDD is not a Java thing. It's not a .NET thing. It's not language dependent. Anyone can do test-first development, for literally any kind of software development.

Figuring out the test for some code is always the hard part... that's why we like to do it first, and get it out of the way.

TestDrivenDeveloper.com is a John E. Boal web site. Please see also my personal blog and my Agile Development blog

TDD | Testing
Monday, February 11, 2008 10:33:29 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
Monday, January 14, 2008
Have you ever wanted to test a table in the database for the correct structure? Ever had someone make a column nullable that shouldn't have been? ever have someone make a column VARCHAR instead of NVARCHAR? INT instead of BIGINT? SMALLDATETIME instead of DATETIME? This is an easy way for bugs to creep in - when the code is written for one version of the database and then someone makes a change... So if you haven't been testing your tables (SQL should be TDD'd too), perhaps you should...
 
Here is a handy stored procedure you could use that describes a table in an easy-to-test way.
 
CREATE PROCEDURE describe (@table_name varchar(90))
AS
SELECT DISTINCT
  sc.column_id as ColumnNumber,
  cols.column_name as Name,
  cols.data_type as Type,
  ISNULL(cols.character_maximum_length, 0) as Length,
  cols.is_nullable as Nullable
FROM

  information_schema.columns cols

  INNER JOIN sys.columns sc ON

    cols.column_name = sc.name

    AND OBJECT_NAME(sc.object_id) = @table_name

ORDER BY sc.column_id
 
Just call it with the table name and it produces a nice format the tests can use to extract the info they need to check.
 
# Name         Type     Length Nullable
1 Id           int      0      NO
2 TypeId       int      0      NO
3 Name         nvarchar 50     NO
4 Description  nvarchar 1500   NO
5 CreateDate   datetime 0      NO
6 UpdateDate   datetime 0     YES

just employ a data reader to read the data in the test, and your unit tests can ensure that all of the tables have the right structure.
SQL | Tools | Unit Tests
Monday, January 14, 2008 8:15:53 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]  | 
© Copyright 2010, John E. Boal