|
PIEBALDconsult wrote: Dagnabit! Frowny faces?! Who wrote this crap?
Paging Chris Maunder. 
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
-- Matthew Faithfull
|
|
|
|
|
Hum, unless the copy paste messed something up this is not creating a match for me.
|
|
|
|
|
With the SPACE between the : and ( you need to use
System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace
to ignore the extraneous SPACEs, but then the # and everything after it become a comment! 
So now I've escaped the the # to \x23.
Resulting in:
System.Text.RegularExpressions.Regex reg = new System.Text.RegularExpressions.Regex
(
@"^\s*LIC\x23\s*: (?'LIC'.*)YRMD\s*: (?'YRMD'.*)MAKE\s*: (?'MAKE'.*)BTM\s*: (?'BTM'.*)VIN\s: (?'VIN'.*)$"
,
System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace
) ;
Whoops, I had left out an asterisk I had meant to include: VIN\s*
modified on Friday, March 21, 2008 2:35 PM
|
|
|
|
|
Quick little edit to get rid of the extra space that was being captured.
^\s*LIC\x23\s*: (?'LIC'.*)\sYRMD\s*: (?'YRMD'.*)\sMAKE\s*: (?'MAKE'.*)\sBTM\s*: (?'BTM'.*)\sVIN\s: (?'VIN'.*)$
|
|
|
|
|
Hey, I was leaving that for the OP to do; I didn't want to solve the whole thing for him. 
|
|
|
|
|
Sorry, I was bored and happened to have The Regulator open. At least now I can enjoy the weekend in knowing that I accomplished something today. 
|
|
|
|
|
Thanks all, your comments and examples have been very inlightening
modified on Friday, March 21, 2008 6:15 PM
|
|
|
|
|
|
Hi all,
I was just wondering about the following problem. I often write device drivers for various hardware systems. Often I put all that code in a DLL which can be called by another program. Usually I'll need to put in a form somewhere to allow the user to change parameters and settings. Normally this form is in the program that accesses the dll which is all well and good.
Thats all fine, but I got to wondering does anyone know how to put a windows form with buttons and stuff inside a dll? Could I use the forms editor like I would If I was producing an exe or would I have to hard code everything?
Its just that I figured it would lead to a much more modular and potentially better design because all the configuration and control is in one place.
|
|
|
|
|
Just create a C# Class Project and create your forms there, as per normal.
|
|
|
|
|
That was quick! So literally it is just as simple as the process for writing a new exe file then. Thanks I'll have to try it.
|
|
|
|
|
Thanks I tried it and it works just fine.
I needed to simply add a form to the dll class and add a method inside the dll that shows the form. Another program can simply call the method inside the dll to display to form. - Thats just great.
|
|
|
|
|
I've been rummaging around in nUnit and experimenting with it, and I have a question about properly using it.
It seems to me that it's only real purpose is to test discrete functions and classes, and really isn't applicable for testing the application that uses the "units". Am I just missing something?
Next, I understand that TDD is supposed to promote the building of tests before doing the actual coding, but what about adding nUnit to existing code? It seems kinda pointless unless you're doing a ground-up redesign of your code.
I've been a programmer for almost 30 years, and didn't really understand the reasoning behind "extreme programming", and think "agile programming" is the sure path to failure in a production product. TDD makes a lot more sense in theory because you have to have a good design up front in order to write applicable/viable tests, which leads (theoretically) to better core code sooner in the process.
Please be gentle in your protestations and guidance - remember, I'm REALLY new at this TDD stuff.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi John,
first of all, wrong forum. Your message does not contain a single C# item
I have been using nunit occasionally, and yes I too think it is more suited for
testing the lower levels of a program, a library, the business logic, etc;
and less for a GUI, or an entire app.
That does not change the value of TDD though, it only tells me we may need or want
other tools as well.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: first of all, wrong forum. Your message does not contain a single C# item
I knew I shoulda brought a gun to this party...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: and didn't really understand the reasoning behind "extreme programming", and think "agile programming"
AFAIK, these are successful when you are doing an application which don't have a proper requirement specification in hand. If you have the complete requirement and design document with you, then these are kinda pointless. Concept is, when new changes are made to the system, automated tests will ensure everything else is functioning correctly.
I tried this approach and liked it very much. The project which I worked don't have complete requirements when I started it. So I created test cases for the functionalities which I wrote. When I get new requirements, I were able to make changes without looking to the other parts of code, automated tests will fail if the new change is affecting somewhere.
Hope this makes sense
|
|
|
|
|
John Simmons / outlaw programmer wrote: it's only real purpose is to test discrete functions and classes
That is my understanding as well. Which isn't necessarily a bad thing.
John Simmons / outlaw programmer wrote: adding nUnit to existing cod
The only way that this would make sense to me is if you added unit testing on an 'as needed' basis and not try and add unit testing to the entire code base. Evolve it over time.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
|
|
|
|
|
Well not surprisingly I don't agree with the replies you have so far received.
John Simmons / outlaw programmer wrote: It seems to me that it's only real purpose is to test discrete functions and classes
NUnit is for Unit testing and discrete functions, classes and modules are the primary purpose of Unit Testing. You can however expand that meaning and the use of NUnit to be pretty much whatever you want. However I don't believe that attempting to do system testing or regression testing with Unit test tools is a very productive way to do those types of testing.
John Simmons / outlaw programmer wrote: Next, I understand that TDD is supposed to promote the building of tests before doing the actual coding
Yes, um, No, well maybe. It's like with any other process, they should be tailored to your individual environment and project.
John Simmons / outlaw programmer wrote: but what about adding nUnit to existing code?
You don't "add" NUnit to your system code. If that is what you are doing you are doing it wrong.
John Simmons / outlaw programmer wrote: It seems kinda pointless unless you're doing a ground-up redesign of your code.
No you can certainly write NUnit Unit tests for existing apps without modification to the application code base.
NOTE: We tend to put all NUnit tests in a "Test" project as part of the Solution.
John Simmons / outlaw programmer wrote: I've been a programmer for almost 30 years
Oh dear, what happened to you? 
John Simmons / outlaw programmer wrote: didn't really understand the reasoning behind "extreme programming", and think "agile programming" is the sure path to failure in a production product.
The rise in popularity, as with anything in our profession, causes much abuse and misuse due to assumptions that people know what it means. Mostly they don't. There was a common struggle regarding requirements. Some assumed you should have them all before starting development. We know of course know that is very very rare as requirements almost always constantly change. Agile was borne as an attempt to standardize the fact that requirements almost always change during the original development cycle of a project. There are many different prescribed agile processes and most of them share one common trait. That you tailor the process to your environment and project. Easy to type, not so easy to do. 
I have been a programmer for almost 20 years now and I have always done Unit tests. Not always test drive, and certainly not with tools like NUnit that make it a real breeze to do. I still don't do test driven in a Nazi like fashion but I agree that thinking or even writing test (in some cases) can be helpful to your thought process about designing and developing your project.
One of the most productive aspects of having Unit Tests as early as possible is that when requirements do change you can update the module and run all those tests to ensure you haven't broken anything.
Well you have probably stopped reading by now so I guess that's enough.
led mike
|
|
|
|
|
nUnit can be used with existing projects. Anytime you change code writing unit tests really helps with the testing to identify errors. You will find, however, that writing good tests cases requires a lot of time. Sometimes when I have really bad code a unit test is the only real way to identify the errors.
Also, if you find yourself testing the results from a database call you are using unit testing wrong and have slipped into integration testing which is different and the two shouldn't be mixed.
I ramble a lot, unit tests do not test the application just the code. The theory is that if your code works as promised your application is more likely to work as expected. You still need traditional testing even with the best TDD.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
I just picked up a book about TFS and Agile. The author really seemed to be saying that XP was the cure to all evils and nothing else could be used to write good software, no other methods used iterative delivery, etc.. His view also was that XP was an all or nothing thing, you either implemented in all, including paired programming, or it wouldn't work. My response to this...well, not kid sister safe.
Just like any methodology, you have to adapt it to the environment.
I think one of the misconceptions with Agile is that you don't need good, or any requirements, to do work, it will all get worked out in the iterations. The last client I was at said they were using Agile, I liked to think of the methodology as more of the pasta cook method, through it against the wall until it sticks. They were so far behind schedule because the requirements kept changing, not to mention the recreate the wheel syndrome.
As for unit testing, I always create tests (with VS) for my backend code, whether the client wants it or not. I've had too many cases where testers complained because the app wouldn't work correctly and blamed my code. Running the unit tests showed them it was either bad input or data.
Maybe someone should move this thread to the Lounge
only two letters away from being an asset
|
|
|
|
|
Welll, I'm more interested in the TDD stuff - I threw in the XP and agile thing so everyone was aware of what I skipped.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Mark Nischalke wrote: The author really seemed to be saying that XP was the cure to all evils and nothing else could be used to write good software, no other methods used iterative delivery, etc.. His view also was that XP was an all or nothing thing, you either implemented in all, including paired programming, or it wouldn't work.
While he may be right or wrong, XP is not Agile. It is only one particular agile methodology.
If you really want to know what the intention of agile is you go the horses mouth.[^]
AM is an attitude, not a prescriptive process.
led mike
|
|
|
|
|
led mike wrote: AM is an attitude, not a prescriptive process.
Yeah, thats where I've seen a lot of people go wrong with many of the methodologies. It's not about checking off on a line item, behavior has to change also.
led mike wrote: the horses mouth
Why did I have thoughts of a link to a Mr. Ed site?
only two letters away from being an asset
|
|
|
|
|
John Simmons / outlaw programmer wrote: It seems to me that it's only real purpose is to test discrete functions and classes
NUnit can be used to test your whole application, but just parts of it at a time. Unit testing doesn't work for integration tests or tests where you want to see if 2 or more components work well together. Unit testing is just that: testing a unit at a time. In practical sense, this means testing a single method at time.
There are some barriers to unit testing: if you've mixed logic code in your GUI classes, unit testing them may cause your forms and controls to show up during the unit test runs, slowing things down and making testing a real pain. That's bad. Separate your logic from your GUI and you'll be good. Then you don't write unit tests for your GUI classes since there's no logic to be tested.
Another barrier to unit testing is hard-coded dependencies on the file system, the network, databases, etc. For example, if you've got a function that should open a connection to a database, and you want to test that the database is opened, you're in a predicament: your test can actually open the database, but that can slow down unit tests and it might not work if run on certain machines. Instead of opening a real database, make your code flexible enough so that there's no hard-coded dependency on your database:
void OpenTheDatabase()
{
someSqlConnection.Open();
}
void OpenTheDatabase(IDbConnection connection)
{
connection.Open();
}Here you injec a connection object, which could be a dummy object you create in your tests:
[Test]
public void OpenTheDatabaseDoesExactlyThat()
{
DummyConnection connection = new DummyConnection();
myDataLayer.OpenTheDatabase(connection);
Assert.IsTrue(connection.Opened);
}
class DummyConnection : IDbConnection
{
public bool Opened = false;
public void Open()
{
opened = true;
}
}Ah, now your test doesn't actually talk to a database during the unit tests.
It's a contrieved example, sure, but you get the idea: replace hard-coded dependencies with fake objects. For a better example, see Martin Fowler's Dependency Injection[^] article.
Now, once you've done a few unit tests like this, you begin to realize it's really a pain to have to create dummy classes like our DummyConnection every dang time you want to replace a dependency with a fake object.
Fortunately, there are some real great pieces of code out there, mocking frameworks, that take care of this for you. At my job we use a free one called RhinoMocks[^]. With it, replacing dependencies with fake objects becomes a breeze:
[Test]
public void OpenTheDatabaseDoesExactlyThat()
{
using (rhinoMocks.Record())
{
IDbConnection fakeConnection = rhinoMocks.CreateMock<IDbConnection>();
fakeConnection.Open();
}
using (rhinoMocks.Playback())
{
myDataLayer.OpenTheDatabase(connection);
}
} Notice in the above example, there is no DummyClass we had to create. Also notice we didn't have to Assert that Open() was called on the IDbConnection object -- we just told RhinoMocks we were expecting connection.Open to be called, and that was it.
John Simmons / outlaw programmer wrote: but what about adding nUnit to existing code?
You mean unit testing already-written code? Since that code's probably gonna be hard to test, it's gonna be hard to do. Skip the elementary nUnit and go for something more powerful. TypeMock[^] allows you to unit test existing codebases that weren't built with unit testing in mind. (It's so powerful, some people look down on it[^] because it allows you to write code the "old" way: hard-coded dependencies, tight coupling, etc. and still do unit tests.)
John Simmons / outlaw programmer wrote: TDD makes a lot more sense in theory because you have to have a good design up front in order to write applicable/viable tests
Precisely. It makes you essentially write blue prints for your code before actually writing the code. If you've got tests like ListensForUserModification(), SavesToDatabaseWhenClosing(), you've got a blueprint for how your code should work, and you've already put some thought into the design before actually writing code.
|
|
|
|
|
Heres one for you all.
I need to get info out of the data base by status and the current week. This is not a problem except for that the Week needs to begin on Thursday at 5:00pm and end on Thursday at 4:59pm.
I suppose my Question is how do I set this time as my week?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
