If you're in my position you have a big WebForms applications which have escalated to this unmaintainable thing. Things break when you add new features and you need an inexpensive maintainable way to do some kind of automated testing.
Now, from my understanding, the right thing to do would be to try building an abstraction layout of the page and user control model present in ASP.NET WebForms however, seeing as it would require a major investment in an existing application it is not an option.
I'm trying and pushing for a REST-like development as much as possible because it has some nice properties. And while doing this I've written a simple spider bot that crawls all URLs it can find and tries, simply getting them.
This allowed my to quickly find bad data that was causing problems and avoid having my end-users clicking on broken things, however, this is of course not enough.
I continued work on my crawler and it's developed into a simple REST client that tries different input combination, looking for a probable bug or crash. It's more intelligent that just an exhaustive search (because it knows about the ASP.NET WebForms application layer) and my goal here is to basically explore the state of the web application, hoping to hit all the corner cases before our users.
Does anyone have any experience doing something similar?
Also, for you test gurus out there. Is this a complete waste of time, or will I be able to actually say something about the quality here? From my perspective it seems to hit a sweet spot in that it will try things a potential end user would though a browser.
As I said before, we're stuck in a bad place. And we need a simple way out of it, right now.
We've tried things like Selenium, but it mandates a lot of extra work and we change things all the time, it's just no possible to maintain multiple selenium test suits for 50 different applications.
Of all the types of testing to implement, unit testing is both the easiest and the most likely to yield results, in terms of less bugs and more maintainable code. Get that worked out before you deal with automated integration testing
Pick an IOC Container - I like Ninject for this personally
Find a convenient place to inject "service" classes into your Page (the consturctor of a base Page class or override the module that loads pages, whatever works for you)
Pick a unit test framework and if you don't have an automated build then set one up; include running a full suite of unit tests in that build
Every time you go near a piece of logic in an aspx.cs file, see if you can't isolate it in a service and wrap unit tests around it
Take a look at whether the MVP Pattern would be good for you - we found it decreased productivity as much as it increased testability (it did both a lot), but it works for some people
See about slowly migrating your app over to MVC, a page at a time if necessary
And remember, you are not going to fix this problem overnight, you don't have time. Just keep improving test coverage and you'll see the benefits over time.
What part of your application is breaking? The UI, or the business logic?
Business logic should be completely separated from the user interface, and should be tested separately. In particular, it's much easier to use automated unit testing tools against separated business logic than it is against UI.
If i am rigth you have a large web form and want to run some standard end user tests each time you do a new release.
I can recomend the Selenium IDE adon for firefox.
it will allow you to record your user actions, e.g filling in a form, and allow you to replay those actions at any time. an easy way to run some test over a form with differnt data.
For internal code testing write some Unit tests using NUnit
Related
We are introducing E2E tests in some of our Single Page Applications (SPA) and are really inclined towards using testcafe for it. Since SPA's take a long time to load and provide fast subsequent navigation we are using experimental disablePageReload feature in testcafe because without it the tests take too much time to be usable.
I followed this issue #1770
and wanted to ask this question there but the comments have been disabled.
On the issues mentioned by a collaborator in the link above on why this feature is experimental, my thoughts are as below (collaborator comment with my thoughts)
We assume that it's hard to write tests so that they don't require page reloads, which makes this feature difficult to use.
On some level this is true, but in SPA we rely on the framework to do the navigation and a simple state or route reload effectively makes the tests independent. Of course, there could be some application state that could linger on a state or route reload but that is something the application owners have already taken into account. Once a decision to write a SPA is taken, it's expected that users are using the framework navigation instead of full-page reloads inside their own browsers
We think that writing tests in such a way affect their stability.
Yes in case of memory leaks or other interference between tests, there could be some instability between tests but achieving stability by page reloads would be a fake one. SPA users are expected to have long sessions without reloads, which means the tests should be independent without page reloads.
There are some aspects of this feature that aren't finished yet. For example, using this feature when tests are run concurrently.
This is something I would like details on. I have successfully used concurrent tests in my small pilot project. But this is something the collaborators must understand better.
I only want to know, if there is some direction on this feature to be officially implemented or this will be removed eventually. It's very important for the decision at my company.
Thank you for sharing your own view of this feature.
Currently, we still receive messages from users interested in its official implementation. So, we decided to continue working on developing this functionality, but, at the moment, I cannot give you any estimates on when the feature will be published.
I'm working with a large mature php codebase that I'm considering making a case for automated testing for to the management. As part of this I want to have the core of a usable testing suite in place to demo the impacts on our completion times ect. Only thing is, I'm pretty much a novice at automated testing myself and theres a couple of real life considerations I'm not altogether clear on.
For one thing how do I include my tests in git? I don't want to push them live!
For another I clearly don't want to create dependencies in the production code on a testing tool. So should I be writing the tests to load the main application into them as a preamble to the actual tests? (This would seem to imply a mirror directory structure for tests is needed in our development environments).
Lastly I am leaning toward PHPtest and/or selenium to run the show. In particular I want to test browser test results including html and subsequent js and ajax operations. Selenium seems ideal for that but I'm unclear on how I would integrate it into the codebase. I assume its Javascript but I'm unclear on that. The remaining features that aren't user accessible would then be tested by PHPtest, a fairly small number of items I would assume. Does that seem in any way sane?
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).
I have a portfolio made in C#/ASP.NET which started off small but, as it is selling myself, it has grown in size very quickly.
I started off with using ASP.NET webforms model but this has meant that some of my code is in class libraries (.dlls) and some in page codebehind.
I want to fix this (no defined stucture), but without the overhead of migrating to ASP.NET MVC or WCSF.
How could I address these problems? I am thinking of moving all logic to WCF services and calling them from page codebehind. Is there a better way?
EDIT: The current problem is codebehind (used only as the site was small at the start but now it gets a lot of attention from me with updates). I want to seperate this all out so it's easy to test (what MVC addresses), and the coupling is generally low. Is it enough to use WCF to achieve this? What other techniques could I employ? Maintainability is another concern because maintaining a codebase split between .dlls is awkward (when debugging, as I noticed and mentioned in some previous threads).
Thanks
Unfortunately, traditional web forms applications are damn near impossible to test. WCF won't be of much help because it's a communications technology that will help you to get the data to codebehind classes but won't help you to render or test pages.
Due to this complexity, there are very few test automation tools, and the few there are are commercial paid-for products. One such tool I have heard of, but have not used personally, is Ivonna. You can also test using browser automation. Two great tools to help with this purpose are watin and WebAii.
This is, of course, dependent on whether you still want to keep the original code lying around. What I take in when I read your post is that you want all of the benefits of MVC. Unfortunately, it may be best to take the plunge and rewrite the application. It's painful, I know, but the sheer amount of hackery to make WebForms ape MVC concepts is overwhelming, to say the least.
I cant fully imagine what you need, but consider URL redirection / slug
What's the best way to automate testing the UI in an Asp.net Page?
Watir or Watin are a great place to start.
More info here
Quite loosely defined question so a good answer is almost impossible.
Would dare to suggest that using Selenium might help with automating the task.
If you are the only coder on a project, I would suggest testing it by hand. That said, you will likely suffer from coder myopathy. Since you wrote the code and know what it is supposed to do, you may subconsciously avoid actions that will break it.
I have worked with different automation methods and they tend to be fairly heavy. In other words, you will find yourself working on updating your tests more often than you would like. In my opinion, automated testing only becomes necessary when you have more than one developer on a project and they are not aware of the full scope.
In the ideal environment, a developer would have a dedicated tester who would write and maintain tests, as well as validate that the code was functionally correct and met the business requirements.
In the real world, lots of developers are basically lone wolves with limited resources and time and the best way to have solid, bug-free code is to understand the business requirements and then make sure that when writing the code, you make no mistakes. :-)
Not sure about the "best" way, that's probably quite a loaded question...
One way is to use the Web Tests in the Test edition of Visual Studio, see MSDN documentation.
Also here's a simple tutorial.
What specifically are you testing for? Cross browser compliance? Performance? Usability? That's a pretty broad question - can you define it a little more?
In terms of User Acceptance? Bug hunting? Load testing?
For the first one, get other people to use it and comment on it.
For the second one you should use your test plans and test cases that you wrote beforehand to test the UI, in terms of data validation (server-side as well as javascript), range checking and all that stuff. I believe there are tools that simulate clicks as well that you could use.
For the third, try JMeter.
As for testing the engine behind the website, you can bypass the web interface and write test classes that call the engine directly (if it isn't coded directly into the ASP) to test its functions. I would call this a different task to testing the UI however.
AspUnit which can be found on SourceForge.net. However the project is no longer actively developed but it will work on .Net 1.1 and 2.0.
Setup a room with several terminals
running your application
Prepare a list of tasks to be
completed
Bring in volunteers to run through
the tasks
Monitor the actions of the
volunteers either through taping or
a one way mirror
Rinse and Repeat!
I vote for Test Manager in Visual Studio 2010 and then generate "Coded UI tests" for it!
Very easy to create assertions
Very nice code (Readable!)
Easy and maintainable, because the code is easy to read and you can change the way how controls are found on the page
I did a quick comparison or WatiN, Selenium and Test Manager VS2010