0

Have a stored procedure that produces a number--let's say 50, that is rendered as an anchor with the number as the text. When the user clicks the number, a popup opens and calls a different stored procedure and shows 50 rows in a html table. The 50 rows are the disaggregation of the number the user clicked. In summary, two different aspx pages and two different stored procedures that need to show the same amount, one amount is the aggregate and the other the disaggregation of the aggregate.

Question, how do I test this code so I know that if the numbers do not match, there is an error somewhere.

Note: This is a simplified example, in reality there are 100s of anchor tags on the page.

O.O
  • 11,077
  • 18
  • 94
  • 182
  • Depends on the kind of testing. You can test the Stored Procedures in isolation. You can test the data retreival routines (the difficulty of this depends on how abstracted your data routines are, i.e. IRepository makes this easy). Rendering the rows, well, you'r reliant on the browser for that. There are Client-Side testing suites that will test the entire process (I believe there is one called Want-It but 10 mins Googling hasn't been productive) but that is a field I'm not experienced in. HTH – SeanCocteau Feb 24 '12 at 17:38
  • @SeanCocteau - I use only ado DataTables. I need to compare the two values, where to do it I don't know. I'm not interested in testing the rendered output as I am the number of datarows in the two DataTables. – O.O Feb 24 '12 at 17:50

2 Answers2

1

This kind of testing falls outside of the standard / code level testing paradigm. Here you are explicitly validating the data and it sounds like you need a utility to achieve this.

There are plenty of environments to do this and approaches you can take, but here's two possible candidates

  • SQL Management Studio : here you can generate a simply script that can run through the various combinations from the two stored procedures ensuring that the number and rows match up. This will involve some inventive T-SQL but nothing particular taxing. The main advantage of this approach is you'll have bare metal access to the data.

  • Unit Testing : as mentioned your problem is somewhat outside of the typical testing scenario where you would oridnarily Mock the data and test into your Business Logic. However, that doesn't mean you cannot write the tests (especially if you are doing any Dataset manipulation prior to this processing. Check out this link and this one for various approaches (note: if you're using VS2008 or above, you get the Testing Projects built in from the Professional Version up).

Community
  • 1
  • 1
SeanCocteau
  • 1,838
  • 19
  • 25
  • All the business logic lives in the stored procedures, my DAL and BLL layers simply return the populated ADO DataTable object to the databindable control. I guess that would mean the first bullet is the way to go. Unit testing appears to be too inadequate to handle this sort of testing (where the values of the input parameters need to come from database tables). Would you agree? – O.O Feb 27 '12 at 17:41
  • In a broad sense the principal of Unit Testing is probably not applicable here. That said, a Testing Project still provides an adequate development / compile environment that is geared towards testing so there is no major reason why you couldn't call your SPs from there + it is a slightly better coding environment than plain old T-SQL, but that's just me. HTH – SeanCocteau Feb 28 '12 at 09:04
0

In order to test what happens when the numbers do not match, I would simply change (temporary) one of the stored procedure to return the correct amount +1, or always return zero, etc.

Ben
  • 398
  • 2
  • 8