It seems like a fairly large hassle to set up a proper debug environment in ASP.NET and I'm just wondering if using Asserts are the way to go or not. I've read a bit and saw that you need to modify your web.config to properly use Asserts. Is this usually the best way to go or are there other methods of debugging that might be easier to use?
We don't use a unit testing framework so that isn't really relevant to the question.
How do you know the difference between them working properly or not working at all? Currently I can put in asserts in my code and it will do absolutely nothing because they are not configured in the web.config. This seems dangerous to me.
I would direct you here: When should I use Debug.Assert()?. There are several good answers that can tell you when it's good to use them, and you can figure out from there if it's worth it in your app.
Having Debug Asserts will ensure your code is correct. With the right combination of test cases will definitely help you.
Several Unit test frameworks come with handlers that can log messages and throw exceptions on asserts. Choosing one of these framework or writing your own handler is something that you may have to think about. But once the Unit test code catches these exceptions, they should be logged and marked as failed.
Related
I found many languages provides some way to change code runtime. Many people ask queries regarding how to change code in this or that language runtime. Here I mean by change code is that rewrite code itself at runtime by using reflection or something else.
I have around 6 year of experience in Java application development. I never come again any problem where I have to change code at time.
Can anyone explain why we require to change code at runtime?
I have experienced three huge benefits of changing code at runtime:
Fixing bugs in a production environment without shutting down the application server. This allowed us to fix bugs on just some part of the application without interrupting the whole system.
Possibility of changing the business rule without having to deploy a new version of the application. A quicker deploy of features.
Writing unit test is easier. For example, you can mock dependencies, add some desired behaviour to some objects and etc. Spock Framework does well this.
Of course, we had this benefits because we have a very well defined development process on how to proceed on this situations.
At times you may need to call a method based on the input, that was received earlier in the program.
It could be used for dynamic calculation of value based on the key index, where every key is calculated in a different way or calculation requires fetching required data from different sources. Instead of using switch statement you can invoke a method dynamically using methodName+indexOfTheKey.
Is it possible to add or remove scripts from a bundle based on the debug setting of the application?
I.e. Given a bundle definition of-
var jQueryBundle = new ScriptBundle("~/js/main").Include(
"~/Scripts/jquery-1.{version}.js",
"~/Scripts/jquery-migrate-{version}.js",
"~/Scripts/script.js");
Remove the jquery-migrate reference when the site is not running in a debug profile, or conversely add it under debug.
Nb. I actually came up with a solution to this whilst formulating the question, I have tested it and it seems to work. I have answered it but left it unaccepted for now should a better solution present. In the mean time the answer will at least now be available for reference should anyone want to make use of it.
I actually came up with an answer to this whilst writing out the question. Since I hadn't been able to find an answer through searching I decided to post the question anyway and answer it - both so it is available as reference for anyone else wanting to do the same thing, and to get feedback from wiser minds than mine if this the most performant way of achieving this - or even a sensible thing to do.
var jQueryBundle = new ScriptBundle("~/js/main").Include(
"~/Scripts/jquery-1.{version}.js",
"~/Scripts/script.js");
if (HttpContext.Current.IsDebuggingEnabled)
{
jQueryBundle.Include("~/Scripts/jquery-migrate-{version}.js");
}
bundles.Add(jQueryBundle);
I have tested this and whilst debugging the script is listed (I have retained the defaults of bundling and minification left off in debug mode) and whilst running normally the contents of the migration script were not in the combined minified script. Over the next couple of days I will profile this to compare to "vanilla" bundling to see what (if any) performance impact this has on application start.
I'm still trying to understand and use Use Cases and Test Driven Development, but having a hard time crossing the line. I'm hoping someone can provide a good example of how setting a datasource and/or databinding a gridview could be accomplished using Test Driven Development.
Here is my pseudo approach at it.
Create an aspx page and add the gridview control to it.
create a method in the code behind called BindGrid(datacollection,gridview) that passes the collection and gridview to a method in a class outside my website so I can actually write the Unit test for the method, and returns a databound gridview.
On the BindGrid method, I right click and select "Create Unit Test" which creates a new test project for me with an outline test for my BindGrid() method.
Now I guess there are a number of test I could write, for example: testTrueDataCollectionBindstoGridView() to see if the collection datatype actually binds? I'm not sure the other test to write?
This is how I currently understand I would go about TDD and Unit testing my example. It feels very clumsy and I'm hoping for some feedback as to what I'm doing wrong, and ideas for improvement.
Thanks
Update:
I've decided to try to simplify my question in hopes of getting more ideas.
How would you go about writing a test for a collection binding to a control? For example say I wanted to bind a dictionary to a drop down list. What test should I be writing, and how would I go about writing them?
Thanks
To some extent, your question describes why the ASP.NET MVC frameworks was created. It is very difficult to write tests against the ASP.NET Web Forms model (of which the GridView is part of). Also, you seem to be close to writing tests to test the Framework itself, not the code you are writing. If you go too far down that path you will write tests forever and never release any code. It would be more productive, in this case, to seperate out whatever code you used to generate the collection you are binding to the GridView and thouroughly test the scenarios around creating that (and especially any exception conditions and possible conditional logic) and trust that the framework binds the data to grid correctly. If the data generation method can produce any exceptions that you want to handle at the UI-level, try test how your code handles that, but again, this is where the MVC frameworks are helpful, b/c it is extremely difficult to test code that needs to be run within the Web Forms lifecycle.
Just speaking in general terms, since I'm mostly doing Java these days and not .NET stuff. I find that TDD does feel rather clumsy at first for most people, but give it some time, and see if you like it or not.
As far as writing tests, take this general approach. Create a method that you want to test, but without any body to it. Create a test that exercises some particular behavior, and keep it simple. Run the test, and it should fail (run red, assuming your IDE does that). Then, write the line or couple lines of code that make the test succeed (go green). Now, write another test, and repeat. If you have conditionals, make sure all paths are tested. That is, write one path, then the other, writing the test for each first.
When you have a method that works the way you want, you can now refactor it to your heart's content, since the test will always be there to check your work. Look at the method. Perhaps there's 4-5 lines that go together, and could be pulled out into a method. Give the method a good name, so that when you're reading the calling method, the name tells you what's going to happen without drilling in. There are other possible refactorings, especially inasmuch as you can see design patterns that you can leverage.
Make sure you re-run the tests frequently as you proceed with your refactoring.
TDD is about adding functionality. It encourages minimal logic in UI components - mostly they should be pure delegates to the code that does the real work, that you can test.
I would recommend, for the purposes of learning TDD, don't bother writing tests about UI behaviour (eg binding data to a control).
To learn TDD effectively, I think a good place to start is try a few code katas. A code kata is a small problem which you do repeatedly. The solution you develop is not the important thing - learn from the process of getting to the solution. So do the problem 10 times, and deliberately choose different designs for the solution each time. TDD is about the process.
There is a list of katas here: http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
The Roman Numerals kata is a good one, but just pick one that appeals to you.
Is there a list of possible faultCode values for Flex's Fault object (mx.rpc.Fault; Flex SDK: 3.4)?
At least faultCodes for faults generated on the client side?
I'm thinking of something like the list of possible runtime errors, found at Adobe's RTE List, but for faultCodes (such as Client.Error.MessageSend, Server.Processing, etc).
Could very well be that I just don't understand my problem well enough to do a decent search, but I've come up with nothing all day. It may also be that there is only one or two client-side faultCode values. Seems like it would make sense that there wouldn't be a comprehensive list of server-side faultCode values, but maybe there's a list of BlazeDS/LiveCycle faultCodes?
Any help much appreciated.
So, it looks like the answer is pretty much "No". I guess this makes sense, I guess, since most server-side faults would come from the server. I figured there would be a list of standard fault types, at least, as part of BlazeDS and/or LCDS.
Here's a pretty good post about setting up exception handling in BlazeDS. Does a good job of explaining why the answer to this question is No, as well as providing a good way of handling exceptions in BlazeDS, which would give you a custom list of fault codes.
http://www.flexpasta.com/index.php/2008/05/16/exception-handling-with-blazeds-and-flex/
Maybe this may help:
There is what they called Fault Event(mx.rpc.events.FaultEvent)
its properties has:
var event:FaultEvent = new FaultEvent();
trace (event.message);
Try adding this in an array so that you could have ur list.
Hope it helps
I have seen several projects that use the Trace functionality to capture events and stream them out to a log file. I have been unsuccessful in finding a simple to follow guide that will show me how to configure Trace to capture and write said logfile. Does anyone have a link recommendations, or provide some simple steps to follow?
The Trace object writes the statements to any attached TraceListeners. You can build your own, but there are a number already defined in the System.Diagnostics namespace, including:
ConsoleTraceListener (Console)
DefaultTraceListener (Visual Studio / Debugger)
DelimitedListTraceListener (TextWriter, special formatting)
EventLogTraceListener (EventLog - anything that inherits from System.Diagnostics.EventLog)
TextWriterTraceListener (TextWriter - think file)
You can, of course, inherit your own from the TraceListener class that writes to where ever you want. For example, you could log to a database, have it send e-mails or pages in certain situations, or write the statements back to a logging platform like log4net.
The big thing is that you need to create an instance of whatever listeners you want and then add them to the Trace' class Listeners collection. You can add as many as you need and Trace will write to all of them. This way, you can write your logging code once using a well-supported and understood object that's part of the framework, and you can attach anything you need to it.
I stumbled into a MSDN article that really helps. Sorry I didn't find it before posting the question but perhaps others may have the same question and haven't found this link.
Take a look at logging frameworks. We rolled out own, but are now migrating over to log4net available free at http://logging.apache.org/log4net/
Im looking for a way to set the Category of the EventLog, the FormattedEventLogTraceListener writes into (not the category of the message).
But I can't find an appropriate property of this class.
Is it possible to set this?