Test Driven Database Development With Data Dude


Published on

In this presentation, we go through the features of Visual Studio Team System Database Edition showing how you can use the refactoring, testing and data generation tools to to Test-Driven Development in SQL Server.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test Driven Database Development With Data Dude

  1. 1. Test-Driven Database Development with DataDude<br />Cory Foy<br />http://coryfoy.com | @cory_foy<br />
  2. 2. Agenda<br />Overview<br />Features<br />Demos<br />Availability<br />Other Tools<br />
  3. 3. Agenda<br />Overview<br />Features<br />Demos<br />Availability<br />Other Tools<br />
  4. 4. Overview – TDD<br />TDD == Test-Driven Development<br />Developer Design Technique<br />Red-Green-Refactor<br />Write a failing test<br />Write just enough code to make it pass<br />Refactor any duplication<br />
  5. 5. Overview – TDD in DBs<br />Why is agility at the database so hard?<br />Control / Permission issues<br />Tightly coupled applications<br />No good testing tools<br />Data Migration issues<br />If it hurts, do it more<br />
  6. 6. Overview – Agile Defined<br />Agile Manifesto<br />Individuals and Interactions over Processes and Tools<br />Working Software over Comprehensive Documentation<br />Responding to Change over Following a Plan<br />Customer Collaboration over Contract Negotiation<br />
  7. 7. Overview – Agile Defined<br />Agile Manifesto<br />Don’t rely on tools and processes to save you<br />Talk to your data experts, your developers<br />Find common ground<br />Make incremental improvements<br />Build a safety net<br />
  8. 8. Overview – Goals of DataDude<br />Integrated Change Management for DB Apps<br />Provide Tools to<br />Manage DB Projects<br />Assess effects of changes to the DB<br />Help work in an isolated environment<br />Help test Updated Solutions<br />Simplify the deployment of changes<br />Facilitate Collaborative Development<br />
  9. 9. Overview - Editions<br />DataDude (2005) (Add on to VSTS)<br />Team Edition for Database Professionals (2008) <br />Visual Studio Team System Database Edition (2010)<br />Comes for free with VSTS Developer Edition<br />
  10. 10. Overview - Tasks<br />Create and Deploy DBs under version control<br />Put existing DBs under version control<br />Modify Offline Representations and deploy<br />Compare Schemas and Data between DBs<br />Develop and run unit tests against DB Objects<br />Generate repeatable test data<br />Refactor database changes across the DB<br />
  11. 11. Agenda<br />Overview<br />Features<br />Demos<br />Availability<br />Other Tools<br />
  12. 12. Features<br />Version Control Database<br />VC a new or existing database<br />Refactor<br />Compare DBs<br />Generate Deployment Script<br />Unit Test Database<br />TDD Schema Changes<br />TDD Business Logic Change<br />Generate Test Data<br />
  13. 13. Agenda<br />Overview<br />Features<br />Demos<br />Availability<br />Other Tools<br />
  14. 14. Demo – Version Control Database<br />Cory Foy<br />http://coryfoy.com | @cory_foy<br />
  15. 15. Version Control Database<br />Existing Schema<br />Two Tables<br /> - Msgs, Users<br />Two Stored Procs<br /> - PostMsg: Posts a message for a specific user to the database. Take a UserID and varchar message as a parameter<br /> - UserInfo: Takes a UserID and returns back all of the user information, including how many posts they’ve made<br />
  16. 16. Version Control Database<br />Get Database Under Version Control<br />
  17. 17. Version Control Database<br />You now have an isolated copy you can work with that doesn’t change the source database<br />
  18. 18. Version Control Database<br />We want to change “Msg” to “Neet” everywhere it exists in the database.<br />This will require a change to the Msg column in the Msgs table, renaming the Msgs table itself, and updating the Stored Procs.<br />We could do it by hand, or we could use the refactoring tools built in.<br />
  19. 19. Version Control Database<br />We use the Refactoring Option to rename the column, and by selecting “Preview Changes” it shows us what it is going to do<br />
  20. 20. Version Control Database<br />We can even see the change in the context of the DDL by clicking on the change in the preview window.<br />When we click on Apply, the change is made to the version controlled local copy. <br />
  21. 21. Version Control Database<br />We also need to change the table name, so we can use refactor for that as well.<br />It detects the need to update the constraints as well<br />
  22. 22. Version Control Database<br />Changing the Stored Proc name can also be done through Refactoring<br />But changes to the values returned from the UserInfo stored proc would have to be done by hand. <br />Also note that the refactorings only look at the database – not your code which accesses or uses the database<br />
  23. 23. Version Control Database<br />We can now compare the schema changes to see how this would deploy it to the database<br />
  24. 24. Version Control Database<br />By Default, choosing to deploy creates a script which can be run to do the actual deploy<br />
  25. 25. Version Control Database<br />We can also choose to have it automatically deploy to a database. For example, here we have it deploying to a local SQLEXPRESS Database<br />And everything should still work (meaning no data loss)<br />
  26. 26. Demo – Unit Test Database<br />Cory Foy<br />http://coryfoy.com | @cory_foy<br />
  27. 27. Unit Test Database<br />We have a new requirement for scalability. Instead of doing a count for user_info, we want a new table which just has a user_id and count. This field should be updated on every Neet by the user, and should be the one queried to get the current Neet count.<br />But, we want to make sure that all of our existing scripts work. Unit Testing to the rescue!<br />Add a new Test Project to our Solution, then delete the UnitTest1.cs file. Then right-click on the Test Project, do a New-&gt;Add Item, and select Data -&gt; Database Unit Test. Name it NewNeetUpdatesNeetCount<br />
  28. 28. Unit Test Database<br />Database Unit Tests execute against a real database connection. So we’ll need to tell it which database to execute against.<br />Note that in this screen we can Execute the tests using one connection, and validate using a different one. This is important when you have your production code which uses a limited access user.<br />We’ll also have it automatically deploy the project to the database before the tests are run<br />
  29. 29. Unit Test Database<br />We now see the DB Test screen. Note that we can have Pre-test, Test and Post-test scripts. These can be used for setting the database into specific states. All tests are written in SQL, and then validated by the Test Conditions at the bottom of the screen.<br />
  30. 30. Unit Test Database<br />What we’re wanting to test is that, with an existing user who as Neet’d before, when we call the PostNeet stored procedure, that the NeetCount table is updated. So our test will look something like this (Arrange, Act, Assert)<br />We’ll then need to remove the default test condition (by clicking the Red x)<br />Then we’ll choose “Scalar Value” from the drop down and hit the plus sign, configuring it to expect that the last query our test runs will return the value “1” in Row 1, Column 1<br />
  31. 31. Unit Test Database<br />Next, we’ll run the test using the built-in runner. Note that the first time you run the tests, it will be slow because it has to synchronize some information.<br />You’ll see the test failed, and if you right-click on the test and say “View Test Result Details” you can see the exact error message<br />The error is that we don’t actually have a table called NeetCount. Well, this will never do, let’s add it.<br />
  32. 32. Unit Test Database<br />So, do we go to the database? Nope – we make the change right from our project. In our schema view, we click on the Tables node, then choose Add-&gt;Table. <br />We’ll name it NeetCount so we stand a chance of having our unit tests pass.<br />We’ll also fill out the DDL to have the columns we are looking for and save it. <br />
  33. 33. Unit Test Database<br />Now we’ll rerun our tests. And they fail again. But for a different reason this time<br />Yep. Our table is there, but nothing is being inserted. How did our table get there? Remember that when we setup the test we told it to deploy the DB project before running tests. So it added the table to the database before running the tests – just by us clicking Run.<br />
  34. 34. Unit Test Database<br />Now that our unit test is failing for logic reasons, we can make the change to the stored procedure. Again, we change it by opening it from the Schema view rather than changing the database directly. But look at the proc. We’ve found our first business decision – at what point should UserID records get inserted into NeetCount?<br />It’s decided that upon user creation a record will get inserted in, and that we’ll need a migration effort to move existing records. With those taken care of, we can focus back on modifying this Proc.<br />(Yes, we’re ignoring transactions, etc for now)<br />
  35. 35. Unit Test Database<br />After updating our test database with the migration of data, we can rerun our tests<br />And everything runs succesfully! Now we know that post a Neet updates the correct count. It’s now time to make sure that UserInfo is pulling the information from the right table<br />
  36. 36. Unit Test Database<br />We create another Database Unit Test called UserInfoGetsCountFromNeetCount. We’ll update the NeetCount for our test user, then execute the UserInfo and we should see the updated count. We’ll start with choosing the Pre-test option and filling it in, then setting the actual test up<br />And running our tests shows it fails for the “right” reason<br />
  37. 37. Unit Test Database<br />So now we’ll modify our UserInfo stored proc to make the test pass.<br />And it does!<br />
  38. 38. Unit Test Database<br />While what we’ve done works, it is better to capture the logic of a change like this in a way that shows the business value and the coupling. Let’s create a new Database Unit Test and call it EnhanceUserInformationPerformance. We’ll add two tests in this for the two conditions we covered previously. Use the Rename button to rename the first test, then click the plus sign to add the second test. Copy over the logic for each from the previous tests, making sure to include the Test Conditions and PreTests<br />
  39. 39. Unit Test Database<br />Now let’s make sure they run. Go to Test-&gt;Run All Tests in Solution and they should all pass. <br />Now, let’s delete the first two tests we created in favor of this new combined test, and rerun all of our tests to make sure.<br />All well and good so far. But we should write one more test which does everything end-to-end<br />
  40. 40. Unit Test Database<br />Add a new Database Unit Test and call it NewNeetUpdatesUserInfo. We’ll use a temp table to capture the results of the UserInfo to compare against our expected values. Note that you *can’t* do this in pre/post test since those run in different connections, therefore the variables can’t be shared. So run the tests and see it green.<br />Right?<br />Or not. So what happened? Remember our Unit Test which updated the NeetTable directly? It’s polluted our DB, which invalidates our results.<br />
  41. 41. Unit Test Database<br />To get around that, we need to either run things in transactions (which we have to do all in the Test Script) or back our changes out. In this case, we’ll just revert the changes at the end of the script in Post Test. So modify the UserInfoGetsCountFromNeetCount test and add the following to Post-test<br />Now go to Test-&gt;Run-&gt; All Tests in Solution and what do we see?<br />That’s much better<br />
  42. 42. Unit Test Database<br />One thing to note about the Database tests – they are all just code and xml underneath. For example, right-clicking on one of our tests and saying “View Code” shows the “magic” happening underneath<br />These are just MSTest unit tests, so you can drop to the code level if there are special things you need to do with the tests.<br />
  43. 43. Demo – Generating Data<br />Cory Foy<br />http://coryfoy.com | @cory_foy<br />
  44. 44. Generating Data<br />In our last demo, we saw the challenges data can cause us. We can use the data generation tool to help us populate the information in our database. Right-Click on the Knitter project in Solution Explorer and choose Add-&gt; Data Generation Plan, then name it TestData. <br />If you click on dbo.Neets, you’ll see that UserID shows as a Foreign Key, but it doesn’t in dbo.NeetCount (because we didn’t add it). Fix that by Right-Clicking on the NeetCount table in Schema View and choosing Add-&gt;Foreign Key. Once you’ve filled it in, deploy it, then refresh the data plan<br />
  45. 45. Generating Data<br />NeetCount.totalNeets is effectively a computed field, but it’s not. So make sure the generator is Integer, and change the properties to be Max and Min of 1<br />We also only want our usernames (UserID in the Users table) to only be AlphaNumeric. So change the generator for that column to be Regular Expression, and in the Properties window, enter [a-zA-Z0-9]*_[a-zA-Z0-9]* then right-click on the UserID row and choose “Preview Data Generation”. As you can see, the characters run the gamut. <br />
  46. 46. Generating Data<br />With our test plan in place, we can have our unit tests use it automatically. Go to Test-&gt;Database Test Configuration and check the “Generate Test Data” box.<br />Now whenever the tests are run, the data is generated automatically.<br />Let’s rerun our tests to show the difference.<br />What a difference! They all fail because there is no UserID “1” in the database. <br />
  47. 47. Generating Data<br />To fix that, we’ll update the tests to select the top user from the users table, making sure we update all 3 tests, and the pre and post tests where necessary.<br />And that looks much better<br />
  48. 48. Generating Data<br />If we do an actual query in our test database, we’ll see that indeed the values get inserted there<br />The Database Edition comes with several generators – for each type, the Regular Expression generator, and Databound generators which can pull data from any connection – other databases, Excel files, CSV files, etc.<br />
  49. 49. Agenda<br />Overview<br />Features<br />Demos<br />Availability<br />Other Tools<br />
  50. 50. Availability<br />Available in VS2005, VS2008 and VS2010<br />Requires a Team Edition of Visual Studio<br />Comes with the Team Edition for Software Developers<br />
  51. 51. Availability<br />Supports SQL 2000, 2005 and 2008<br />Plans are in place to provide data bindings for other platforms but no timeline<br />
  52. 52. Agenda<br />Overview<br />Features<br />Demos<br />Availability<br />Other Tools<br />
  53. 53. Other Tools<br />DBFit<br />Supports Oracle, DB2, SQL Server and MySQL<br />Free of charge<br />Add on to the FitNesse testing framework<br />http://www.fitnesse.info/dbfit:reference<br />http://gojko.net/fitnesse/dbfit/<br />
  54. 54. Other Tools<br />AnyDbTest<br />Supports Oracle, SQL Server and MySQL<br />Uses XML as the backing<br />http://www.anydbtest.com/<br />
  55. 55. Other Tools<br />Agile Data – Scott Ambler<br />Agile Database Techniques<br />Refactoring Databases<br />http://www.agiledata.org<br />
  56. 56. More Information<br />http://msdn.microsoft.com/teamsystem<br />http://www.infoq.com/articles/tdd-dbpro-Foy<br />http://blog.coryfoy.com/2007/07/test-driving-stored-procedures-in-sql-server-in-vs2008/<br />http://www.coryfoy.com<br />foyc at coryfoy dot com<br />@cory_foy on Twitter<br />Slides will be posted on CoryFoy.com<br />