Hugo Estrada's House of Wonder

After doing some research, it seems that there is no clear way to unit test asp .net WebForms.

ASP .Net web forms behavior collides with the current testing principles. The big one being that you only test public methods. Well, it seems that most Web Form pages don't have ANY public methods, making it impossible to test following the unit test principle. For those developers that want to do testing, it means that they have to expose the different private methods that they are using as public methods, breaking a big principle in OOD, which is that public methods are the interface to the object. So the developer who wants to unit test their code either breaks the principle of not testing privates or breaks the OOD principle of exposing as little interface as possible.

So the solutions that I have found either involves some complex code bending to allow for the testing of private methods, doing weird practices such as exposing private methods as public.

The other big solution seems to be to move to the MVC framework. Ideal solution for new projects if one has the time to learn the framework, but won't help that much if one has to work with legacy code.

The one idea that popped into my mind as I was writing this is that maybe it is possible to mvc-ize a bit the code. If every interaction of the page has to rely on objects, then we can test those objects. This seems to have some limitation in that separating database interactions may be difficult, impossible, or create greater problems that it attempts to solve. But at least it, if used properly, allow for testing of potentially breakable parts of the code.

I will experiment with this idea and see what happens.

You initialize it like this:

var membership = Membership.Providers["orclmembershipProvider"];
var validated = membership.ValidateUser(user, password);

A bit different than MS's provider. The name of the provider that you give is the one that you put in the web.config tags.

When trying to install SQL Server 2008, I was running in an error message saying that .NET 3.5 wasn't installed and the installation couldn't go on. Of course, .NET 3.5 WAS installed.

I had run into this problem before, I was going blog about it, but I forgot. :S

So here I am, blogging about it now. I remembered that a file was erased or overwritten. But I couldn't remember exactly what.

The solution is to download dotnetfx35.exe and replace this file with the one that SQL Server 2008 ships with. I couldn't find the original post where I saw this solution, but I found this link that talks about it:

http://www.eggheadcafe.com/software/aspnet/33935610/net-35-installation-...

Answer from stackoverflow

It's a lot easier if you can upgrade to standard/pro and install ReSharper - it's got a really nice integrated test runner. However, if you can't do that...

* Launch the NUnit GUI
* Load the relevant tests, from debug builds
* In Visual Studio, attach to the NUnit GUI process
* Set your breakpoints
* Launch the relevant test

It's a bit of a pain, but when you've got the shortcut keys memorised (Alt-P is attach to process, IIRC - but check) it's not too bad

Last week I ran into a wall while developing email capabilities for a .NET project that I am working on. The problem? The code was correct. The web.config configuration was correct. Even most of the iis 6 virtual smtp service was configured correctly since classic asp code was emailing quite happily.

What was the problem?

After consulting with other developers in the Zekiah developer's list, they told me to check for permissions. Once I was put on the right direction, I found an entry with the solution to my specific problem.

I got this weird error when I was trying to regenerate a designer page:

Unable to convert to web application because the code-behind ".*" is missing

The crazy thing was that the code-behind file was there. The only thing that was missing was the designer page.

The solution was to rename the file. As soon as I renamed it, the designer page was generated. Then I renamed it back to its original name. Done :)

Hmm, the long, exciting description on this error that I had written was erased with a firebug crash. So here is the quick hurried version.

After a lot of troubleshooting why I got a null value from a Request parameter, I figured out that the ProcessRequest() was being executed twice. I looked at some pages, and they said that it could be connected with authentication; I followed some of their solutions, but nothing.

Short Solution:

Wizard.MoveTo(NameOfWizardStepControl);

The long story: