Should we write a Test Case for every Foreign Key?



  • Should I write a test case for every Foreign key in the database?

    Our team is conducting a large database migration project using Java APIs, for eg. inputting CustomerSales.

    And we have ProductId, VendorId, StoreId, MailCarrierId, etc.

    So we are writing test cases for every foreign key column, ensuring if foreign key exists or incorrect. This will lead to 8+ foreign key cases. Its like we are retesting if Microsoft SQL Server knows to enforce its database keys constraints and foreign keys.

    Is that the correct methodology? If so, We will have hundreds of foreign key cases for every table we migrate, not just CustomerSales.



  • I would not use test cases for a database conversion project.

    The task at-hand is database validation to see if foreign key constrinsta have been enforced. This can be developed reagrdles of the conversion. I would use database and dba tools and programs.

    What to do about missing or duplicate records will depend on your target database - same vendor? same size? etc

    Be careful not to get database conversion and database cleanup mixed up until you are sure you want to. Conversely, be carefuly not to put off cleanup to post-conversion - and then never do it which is common in my experiuence.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 3
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2