I have a need to hide a guid used for an index on a .cshtml so I can get model binding on controls dynamically added with ajax (it’s a long story) (that was a mouthful)
I had a hard time finding the value in the hidden field; as it turns out, you can just get it by the attribute on the Selenium element like this:
IWebElement hiddenIndex = driver.FindElement(By.Id("MyControlName_0__Index"));
var indexValueToUse = hiddenIndex.GetAttribute("value");
Refactoring long stored procedures is a drag. There is no way around it. Sometimes it can be terrifying. If the sql you are staring at is an import production proc and you have to make a change to it… Jeesh, I am always amazed at the people who came before me and wrote these things. You would have to be some sort of genius (evil genius?) to get some of the sql I have seen to work. But, often they do work, you just can’t work on them. Not without a change of shorts handy.
Output parameters, 1500+ lines of sql, or a block that looks like this:
Yeah, that’s a pretty good indicator for me. There are several other code smells. You know them. That’s why we are talking here.
Something simple like this works for my logging table:
CREATE TABLE dbo.SqlrefactoringLog (
id INT IDENTITY (1,1) PRIMARY KEY,
LogMessage VARCHAR(250),
InsertDate DATETIME2
)
You can add other columns if you need but this suffices for what I am up to.
In each sql logic block of your large stored procedure, add an insert to your new log table to let you know that you have made into that flow:
INSERT INTO dbo.SqlrefactoringLog ( LogMessage, InsertDate ) VALUES ( ‘block1’,GETDATE())
Once you have an insert in each sql block, 14 blocks in my current case, you will be able to make sure that the integration tests you are about to write exercise each one.
In the work that I am doing now, I an using Entity Framework or NHibernate. Any ORM that you can make work do fine for this. We will be using the objects to populate test data to ensure that we hit all the logic paths that the proc allows for. Using an ORM will speed this up greatly. There is no reason to create all the table objects and write CRUD for them from scratch. Lets use computers to do this…
Feed the list of all the tables in your proc to your ORM of choice and get started. In my case, I have 21 tables (really) across two different databases to test against.
You have to understand this awful procedure to get rid of it. Sorry. To understand it, you will have to exercise each bit of it in a test. Using your new lovely ORMified objects, populate test data and call your proc. Watch your log table, remember him – Sqlrefactoringlog. Keep doing this until you know that you are exercising every code path in your proc with an automated test. Once you are seeing an entry in your log table for every code path, you can have some chance of working on the procedure without introducing regressions.
Once you are exercising all the paths, start capturing the results or outputs of your stored procedure in individual unit tests classes. At a minimum, you will have one test for each code path. I find I often end up with ~3 tests for each code path. You have to think carefully through each one. NUnit, or any automated test framework you know becomes invaluable here.
Ah, if you made it this far, give yourself a pat on the back. You can get out of sql and starting writing code in the language of your choice.
You are going to be replacing this proc with a new library and ORM code or several/many new smaller stored procedures with only CRUD in them. That is the goal anyway. Nothing other than
Wrap the ouput/results of the proc in an object. For me that is a plain old c# object – a property bag in my case. Use this populated object as the expected result for your unit tests. Comment out a sql block and replace its logic in code. If you require a data hit, write a new small proc or use your lovely ORM doing only CRUD to replace that first bit. Start with an easy one if you can – it builds confidence.
Run all your tests and make sure that they still pass. If they don’t – work on your non-sql code until they do. That’s it. Keep going until the proc is gone. Run your tests every time you make a change. Never skip this step. In one of these large complex beasts, not knowing how many steps ago you broke will cause much weeping and gnashing of teeth. Check in to source control each time you successfully remove a block.
Happy Coding,
Jim
Jim Sowers 