nunitasp-devl Mailing List for NUnitAsp (Page 34)
Brought to you by:
jlittle82
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
(26) |
May
(7) |
Jun
(6) |
Jul
(7) |
Aug
(39) |
Sep
(15) |
Oct
(30) |
Nov
(20) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(28) |
Feb
(15) |
Mar
(41) |
Apr
(51) |
May
(32) |
Jun
(5) |
Jul
(14) |
Aug
(19) |
Sep
(33) |
Oct
(30) |
Nov
(35) |
Dec
(95) |
2004 |
Jan
(5) |
Feb
(3) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(9) |
Jul
(8) |
Aug
(32) |
Sep
(15) |
Oct
(6) |
Nov
(22) |
Dec
(1) |
2005 |
Jan
(22) |
Feb
(9) |
Mar
(2) |
Apr
(33) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
(24) |
Sep
(8) |
Oct
(2) |
Nov
(2) |
Dec
|
2006 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Jim L. <jl...@cu...> - 2002-04-09 17:05:49
|
Brian Knowles wrote: > We'll wait for your ideas before we do any kind of > release. There's quite a bit of docs to write before I > feel we can release anyway. The main thing that's bothering me about the code right now is that both Browser and WebFormTestCase are starting feel a little big. It's getting hard to find my way around those classes. I'd like to refactor them into multiple classes. My initial thought involves involves creating classes that can parse and possibly assert on each of the ASP.NET components. Another thing I'd like to do is modify Browser so that it no longer takes a form name argument. I believe that ASP pages only have one form... if so, we don't need a form name. Perhaps we could overload that method. In WebFormTestCase, I'd like to modify the asserts so that the AssertXxxExists and AssertXxxDoesNotExist methods are consolidated into a single AssertXxxExists(boolean exists). I'd like to remove assert methods that we aren't certain to need. Those are the changes I'd like to make before 1.0. I feel that we're somewhat committed to long-term support of an API once we release v1.0, so I want to make the big changes first. I also want to make sure that the API we release is as minimal as possible, since it's easier to add to an API than to modify or remove from it. Longer-term ideas that have been percolating to the surface as I've been using NUnitAsp are XML-based test drivers (for customer-driven acceptance testing) and an in-process component renderer for testing ascx's. I'd also like to see the HTML rendering in NunitGui that Brian once mentioned. And, of course, we need to expand our test cases. > Let us know what your ideas are. There you have it. Sorry you asked? ;) Jim |
From: Brian K. <brk...@ya...> - 2002-04-09 04:30:15
|
> Regarding CVS, I've found Tortoise CVS to be > excellent -- it integrates > with the Windows shell and is VERY easy to use. > Much better than > WinCVS. Haven't tried it with SSH yet, though. I love Tortoise too, I just can't get SSH working with it. > I've got several changes to check in, so folks may > want to hold off on > modifying the two main files. I am losing my .NET development machine Wednesday. I will be out of commision untill I get going at the new job next week. > I also have some > ideas about how to > improve the overall architecture, so I don't want us > to go to RTM or > even RC1 just yet... We'll wait for your ideas before we do any kind of release. There's quite a bit of docs to write before I feel we can release anyway. Let us know what your ideas are. -Brian __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
From: Jim L. <jl...@cu...> - 2002-04-08 21:38:53
|
Regarding CVS, I've found Tortoise CVS to be excellent -- it integrates with the Windows shell and is VERY easy to use. Much better than WinCVS. Haven't tried it with SSH yet, though. I've got several changes to check in, so folks may want to hold off on modifying the two main files. I also have some ideas about how to improve the overall architecture, so I don't want us to go to RTM or even RC1 just yet... Jim |
From: Brian K. <brk...@ya...> - 2002-04-07 22:08:20
|
Between yard work and taxes, I managed to get the VB Sample added and a nice little devsetup script written that will automatically setup the virtual directories and file permissions needed to do development. The one change to production code was the change of the xhtml dtd url to use a local dtd copy instead of the w3c's. The dtd is stored in the web\dtd directory and is mapped to http://localhost/NUnitAsp/dtd. Check the wiki for updated instructions. -Brian __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
From: Brian K. <brk...@ya...> - 2002-04-06 00:03:30
|
Hi all, Alex and I got the directory structure down and the code imported into CVS. Please read the dev env setup instructions at: http://nunitasp.sourceforge.net/cgi-bin/wiki.pl?DevelopmentSetup Go ahead and develop at will. I plan on getting the samples updated for RTM and in CVS this weekend. Please add any comments to the wiki site as they come up. -Brian PS: If you haven't used CVS on SF before, read the SF docs on how it works. You need to use ssh. I recommend using Cygwin's ssh and cvs from the command line. If you can get WinCVS to work, you win a prize. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |
From: Jim L. <jl...@cu...> - 2002-04-03 00:27:52
|
From: ag...@mi... [mailto:ag...@mi...] > > Any chance we could pair on this code sometime this week? I'd like to get > up to speed... I'd like to, but there's no time left in the schedule this week. It's working well enough now that I'm just making minor changes as driven by need, not spending large blocks of time specifically on NUnitAsp. Jim |
From: <ag...@mi...> - 2002-04-02 16:54:57
|
Any chance we could pair on this code sometime this week? I'd like to get up to speed... --Alex Original Message: ----------------- From: Jim Little jl...@cu... Date: Mon, 1 Apr 2002 16:07:24 -0800 To: nun...@li... Subject: [NUnitAsp-devl] Colon problems resolved Folks, I'm happy to report that the problems in the bowels of NUnitAsp have been resolved, thanks to Brian's hint last week. We're now creating our own _headers variable and using that to store parameters instead of _client.Headers. I'm still seeing one problem: NUnitAsp isn't loading the cookie set by FormsAuthentication.SetAuthCookie(.). I created an NUnitAsp test case but it passes (!). However, in Passage Portal, it doesn't. Manual testing works, but in the automated Passage test, it appears that the server isn't actually sending the cookie across the wire. I suspect it has to do with some sort of authentication magic that ASP.NET is doing, so if anybody knows how that works, please speak up. I'm going to hang on to the changes and check them in once Brian gets CVS set up. Jim -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . |
From: Jim L. <jl...@cu...> - 2002-04-02 00:07:44
|
Folks, I'm happy to report that the problems in the bowels of NUnitAsp have been resolved, thanks to Brian's hint last week. We're now creating our own _headers variable and using that to store parameters instead of _client.Headers. I'm still seeing one problem: NUnitAsp isn't loading the cookie set by FormsAuthentication.SetAuthCookie(.). I created an NUnitAsp test case but it passes (!). However, in Passage Portal, it doesn't. Manual testing works, but in the automated Passage test, it appears that the server isn't actually sending the cookie across the wire. I suspect it has to do with some sort of authentication magic that ASP.NET is doing, so if anybody knows how that works, please speak up. I'm going to hang on to the changes and check them in once Brian gets CVS set up. Jim |
From: Brian K. <brk...@ya...> - 2002-03-29 19:56:28
|
Hi Jim, --- Jim Little <jl...@cu...> wrote: >... AFTER the > sex-change operation. Let me know where you're having it, I'll visit and bring some flowers :) > > This is bad news. I was hoping they had fixed the > > HttpEncoding bug with this class. It turns out > they > > did, but now it's just as bad because of the > colon. > > Can't win with these guys. > > What HttpEncoding bug? This was the bug that required us to not put values with spaces in the WebHeadersCollection for the beta 2 version. The value would just disapear without any exception or warning. I assumed that this was because WebHeadersCollection was not properly HttpEncoding the value. There was also some weirdness when the view state had a '+' sign in it. I got around this by HttpEncoding the value myself. > From what I can tell, WebClient (and > WebHeadersCollection) does > absolutely no encoding on the data in the headers. I assumed it did (as of RTM). > As a presentation-layer > tool, > WebClient/WebHeadersCollection shouldn't be > UrlEncoding our data for us, > just enabling and enforcing the HTTP protocol... > which is exactly what > it's doing. I see, I confused this enforcement with an encoding problem. Easy to do when you don't have the source code. I hope the NameValueCollection works! -Brian __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ |
From: Jim L. <jl...@cu...> - 2002-03-29 18:44:55
|
Brian Knowles wrote: > Damn. Here I had my hopes up that you had magically > transformed my pumpkin into a carriage. I can't be a fairy godmother until AFTER the sex-change operation. Sorry! > This is bad news. I was hoping they had fixed the > HttpEncoding bug with this class. It turns out they > did, but now it's just as bad because of the colon. > Can't win with these guys. What HttpEncoding bug? > You might of tried this already, but here goes... > > The Browser class submits the form using the > WebClient.UploadValues method. The signature accepts a > NameValueCollection for the values, not a > WebHeadersCollection (which extends > NameValueCollection), thus we don't need to use the > WebClient.Headers collection to manage our parameters. Ah ha! That might be the fix we need. I didn't realize WebClient.UploadValues took a NameValueCollection. We just looked at how we could make WebHeaderCollection work properly. > ...which gracefully handles names with colons by not > HttpEncoding them or something... I'm not sure if I've made the problem entirely clear, so: From what I can tell, WebClient (and WebHeadersCollection) does absolutely no encoding on the data in the headers. The contents of the headers are an application-layer protocol (not HTTP presentation-layer). HTTP imposes some restrictions on what can go in the headers, but that's it. One popular way to work around those restrictions is to URL-encode the headers... but again, that's an application-layer decision, not an HTTP-layer requirement. As a presentation-layer tool, WebClient/WebHeadersCollection shouldn't be UrlEncoding our data for us, just enabling and enforcing the HTTP protocol... which is exactly what it's doing. ASP.net sends the literal "_ctl0:admin" name as the header, not the URL-encoded "_ctl0%3Aadmin". I believe (but haven't confirmed) that a colon is one of the characters you're not allowed to send as the name of an HTTP header. WebHeaderCollection certainly believes so, which is why it won't let us add "_ctl0:admin" to the header. So, by including a colon in the name of its auto-generated ASP.net fields, Microsoft may be breaking the HTTP specification. Sorry if I'm being redundant here, but it took me forever to figure out what was going on, so I feel a need to get something out of all that work. :) But I think your solution is exactly what we need. I'll take a look at it this evening if I have time. Jim |
From: Brian K. <brk...@ya...> - 2002-03-29 05:56:08
|
> From: Jim Little [mailto:jl...@cu...] Sent: Thursday, March 28, 2002 12:38 PM > Well, that > real-world test found a problem. A BIG problem. > Until we fix it, NUnitAsp > won't be suitable for testing non-trivial ASP.net > pages. Damn. Here I had my hopes up that you had magically transformed my pumpkin into a carriage. > EnterInputData turns around and calls > _client.Headers.Remove and > _client.Headers.Add. Those methods check to see if > the name has a colon, > and if it does, they throw an exception. A colon is > an illegal value in a > name. (I want to kill Microsoft for using a colon. > What were they > thinking??) This is bad news. I was hoping they had fixed the HttpEncoding bug with this class. It turns out they did, but now it's just as bad because of the colon. Can't win with these guys. > Mike and I spent all morning trying to figure out a > workaround for this > problem. We tried bypassing the illegal character > check in > WebHeadersCollection a number of sneaky (and > kludgey) ways... no luck. You might of tried this already, but here goes... The Browser class submits the form using the WebClient.UploadValues method. The signature accepts a NameValueCollection for the values, not a WebHeadersCollection (which extends NameValueCollection), thus we don't need to use the WebClient.Headers collection to manage our parameters. We could implement our own WebHeadersCollectionColonFix (aka: FiberCollection?) which gracefully handles names with colons by not HttpEncoding them or something. This way we could avoid the option below. > At > this point, I think that the cleanest way to solve > this problem will > probably be for us implement our own version of > WebClient. That may not be > as bad as it sounds since we don't need to be as > general-purpose as > WebClient is. Yes this is an alternative, however it immediately adds to the complexity of the project. Perhaps I'm overstating, but I was hoping to avoid this if possible. I suppose, however, WebClient doesn't do a whole hell of a lot anyway. > Other than this "minor" issue, NUnitAsp is looking > very good. That's good. > It's not > quite ready to be put in CVS, yet, as there's some > directory structure > issues that need to be resolved. I've zipped up the > project files and will > go ahead and email them to Brian in a separate > email. I'll look at adding them next week. Thanks for the good work on this Jim and Mike! I think we now have a good beginning from which to get a release going. -Brian __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ |