I'm a testing noob and I need to test a JSF application. So I only just started exploring JSFUnit (read: I've googled it and StackOverflow-ed it), which as I understand uses/extends JUnit, HTMLUnit, HTTPUnit and other units that I have no idea about.
The thing is, the app uses Hibernate and what I want to know is whether or not I can use JSFUnit to create comprehensive tests that encompass model, view and controller, not to mention all that the HTTPUnit supposedly does?
Also, if I'm using Primefaces Dialog Framework so that my dialogs are not in the same page that opens said dialog, would I be able to test this approach? Or would it be better, in terms of testing, if my dialog was on the same page?
I hope my questions make sense. I promise they made sense in my head. Any help in this regard would be highly appreciated.
It seems that you require something more complex than pure unit tests.
Take a look at Selenium framework, as it simulates user interaction through a real recorded use case, and is easy to work with.
Related
Hi one of my client needs unit tested application in asp .net webforms. But I have no Idea about how to start or unit tested applicaton/MVC. I would like to know how to create unit tested application in webforms. Any example, video, tutorial will be helpfull.
Thnaks
I suggest you do the following things:
Start asking your client and yourself what it is you want to achieve? Merely unit testing for no other reason than saying you are unit testing is not a worthy goal to pursue.
Read some introductory book like The Art Of Unit Testing to make yourself familiar with unit testing.
Consider reading this ASP.NET MVC book because it takes you through all layers of an ASP.NET MVC app while applying unit testing at each of those layers (with really good examples).
I agree with point 1 of meilke's answer. Adding unit testing to an existing application can be a lot of work and without a good reason, it's unlikely a customer will want to pay for it. It is possible however to use a request to add or remove functionality as an opportunity to get started. For example, if you have a task to remove some existing functionality then putting a set of unit tests in place to verify the existing behaviour of the application can save headaches later on. Think of it like putting scaffolding in place before doing construction work.
It's not clear from your question but if it's ASP.NET WebForms as distinct from ASP.NET MVC that you are looking to unit test, I would recommend looking into the Model View Presenter design pattern. Here and here are a couple of articles that should help.
I have read/watched so much about TDD & BDD recently that I really want to master it. I have been a developer that only writes code and then tests it from outside (like we always started). The problem seems to be in getting up and running with TDD. I want to just create a simple Winform app in which I want to show a list of something lets say products. I just don't know where to get started, should I write a test for controller first? the controller needs reference to view and service and so on so forth. ASP.Net MVC is built for testing therefore it is a bit easy to get started but Winforms are a real pain. Kindly give me some Videos (Most preffered) that show TDD in Winforms.
I have watched tons of videos that show you testing a class or feature but how do you test UI that does not support testing?
In short I want to know if anyone has been doing TDD for a while, how
does he/she do it in Winforms?
I have written loads of code that I just delete because I get stuck, Please help!
Here's how I do it for any kind of UI, be it Web or Winforms or WPF or Swing in Java or even a web service interface that's going to be used by another system.
Write the UI, and hard-code any data behind it.
Write a controller, and move the hard-coded data to the controller. The controller should just be presenting the data in a form that the UI can understand.
Your controller now has no behavior; just static data - but it's got the right API for the UI, and now you know how the UI wants to use it.
Write an example that shows how the UI will use the controller in the most basic form.
Make the example work.
Write another example that shows how the controller behaves differently in a different context.
Make the example work.
Those are your unit tests! If you know that your controller is going to need some other classes to collaborate with, you can mock those out too.
Once your collaborators are mocked out, you already know how the controller wants to use them. Again, you have the API for those collaborators already, because the controller is using them.
This is what we're doing when we talk about "outside-in" in BDD.
I'm new to TDD too, and just like you I'm trying to learn. Here's what I've come up with during my searches, maybe it will help you too:
Check out Roy Osherove's website, and also his book "The Art of Unit Testing". Check out the videos, there are some great ones, especially the "Pair Programming" section. His book was the single best book that I've read about unit testing and TDD, and the only one that I've read from cover to cover.
Check out some TDD katas. There are some on the web page I've suggested in the previous item. Check out how other people are solving the katas. It's really helpful.
Read about dependency injection.
If you want to TDD in WinForms, check out the MVP pattern. As far as I know, it's the de facto patten for separating UI from business code in WinForms.
Good luck with your search.
The controller is a good starting point. Extract the View public api to an interface an test the interaction of the controller with that interface using a Mocking Framework. You can do the same for the service layer too.
Also, I would take the bottom-up approach for this application and unit test the lower level layers before adding tests to the UI layer. On the UI layer I will write a set of Acceptance Tests using a BDD framework and use mocking frameworks to make those tests lightweight and to reduce the number of tests.
Good luck!
After learning about TDD and unit testing, I'm really looking to write tests when I code, preferably before I code because I see the benefits coding in Python. I'm developing a website, and I'm trying to write tests according to the requirements, but its proving more difficult than expected.
I can see the benefits of writing tests when you're producing a library of code with a public interface for others to use. Developing a website, where there is really not much logic, and mostly Reading and Writing against a database seems a little harder to unit test. Mostly, I have to create/edit/delete rows in the database.
I'm using a framework (Kohana 3 for php), so 99% of all the libraries and helpers that I'm going to be using have already been tested (hopefully), so what else is their to write tests for?
I'm mostly talking about scripting languages, not about CSS or HTML, I already know about cross-browser testing.
How much can you really test when developing a web site, and how should you go about it?
Edit: Is the lack of activity on this question a sign? I understand that certain things MUST be tested, like security and the like, but how much can be written using unit tests and TDD is the question.
Thanks.
Developing a website, where there is really not much logic, and mostly Reading and Writing against a database seems a little harder to unit test. Mostly, I have to create/edit/delete rows in the database.
Not completely true.
You have data model processing. Does the validation work? Do the calculations on the reported rows from the database work?
You have control, sequence and navigation among pages -- do the links work? The test setup will provide a logged-in-user. The test will (1) do a GET or a POST to fetch a page, then (2) confirm the page actually loaded and has the right stuff.
You have authorization -- who can do what? Each distinct test setup will provide a different logged-in-user. The tests will (1) attempt a GET or POST to process a page. Some tests will (2) confirm they got directed to error-response pages. Some tests will (2) confitrm that the GET or POST worked.
You have content on the page -- what data was fetched? The test setup will provide a logged-in-user. The test will (1) do a GET or a POST to fetch a page, then (2) confirm the page actually loaded and has the right stuff.
Have you tried Selenium? It allows you to automatically do almost anything in a web browser. For example, you could have it go through and click all of the links and make sure that they go to the correct url.
It works with multiple languages, including python and allows for testing in chrome, firefox, ie, and other browsers.
If your site contains many forms, how do you write them? Do you write each view using plain HTML? Or do you write your own form helpers that generate forms just the way you want them? If you do that, you may find that unit-testing your form generators makes it easier to write them.
In general, if your program is mostly CRUD, look out for ways to automate CRUD management; write your own custom CRUD generator. Which does not mean write the CRUD framework that will end all frameworks; that would be too much work. Just write a generator for the small things you need for your current application. TDD will help you there.
I m just starting using gwt and so far so good, however after reading some sample code I wonder is it necesary to have a high level of test coverage? (I can see that most code is declarative and then add some attributes I can see the sense in checking so me particular attributes are there but not all)
Also i would be interested to know anything about what are the gotchas in TDDing with GWT
I m using eclipse so also if you are really happy with some particualrs add ins for GWT I would be happy to hear about that
Thanks for the input
edit: maybe I m asking a very wide question, but even little pieces of information will help
I come from having nvelocity views with jquery/extJs/prototype/scriptaculous and this is a bit different
When designing GWT applications to be easily testable, it's best to move as much logic out of the view as possible. Use a design pattern which makes GUI testing easier such as Model-View-Presenter (MVP), which is used widely in building desktop applications (The C#/.NET folks have written a lot about this pattern.)
You can use GWTTestCases to test remote communication and code that ultimately executes raw JavaScript (most of the GWT core classes require this, especially widgets). However, these tests are slow to execute, so you should prefer designs which put all that logic in objects that can be tested in plain ol' JUnit TestCases.
For more information about writing GWT applications test-first, I've written an article for Better Software magazine, which is available as a PDF online at my blog.
I think the best reference at the moment would be this Testing Methodologies Using Google Web Toolkit
I think you asked a pretty broad question, which is part of the reason why you didn't get a reply for a while.
Compared to traditional AJAX web development, one could argue a GWT application requires less testing. Because the GWT team has worked so hard to make sure that its widgets work consistently across all web browsers, you don't have to worry about cross-browser compatibility nearly as much for your own application.
That frees you up to focus on your own application. Create a separate test case for each of your own custom widgets and test that they behave as you expect, and then write higher-level tests for each module. Take the extra step to make your tests fully automatable - that way every time you make a change or are about to release, it's easy to run all of your tests.
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideJUnitIntegration
Unit testing and ASP.NET web applications are an ambiguous point in my group. More often than not, good testing practices fall through the cracks and web applications end up going live for several years with no tests.
The cause of this pain point generally revolves around the hassle of writing UI automation mid-development.
How do you or your organization integrate best TDD practices with web application development?
Unit testing will be achievable if you separate your layers appropriately. As Rob Cooper implied, don't put any logic in your WebForm other than logic to manage your presentation. All other stuff logic and persistence layers should be kept in separate classes and then you can test those individually.
To test the GUI some people like selenium. Others complain that is a pain to set up.
I layer out the application and at least unit test from the presenter/controller (whichever is your preference, mvc/mvp) to the data layer. That way I have good test coverage over most of the code that is written.
I have looked at FitNesse, Watin and Selenium as options to automate the UI testing but I haven't got around to using these on any projects yet, so we stick with human testing. FitNesse was the one I was leaning toward but I couldn't introduce this as well as introducing TDD (does that make me bad? I hope not!).
This is a good question, one that I will be subscribing too :)
I am still relatively new to web dev, and I too am looking at a lot of code that is largely untested.
For me, I keep the UI as light as possible (normally only a few lines of code) and test the crap out of everything else. At least I can then have some confidence that everything that makes it to the UI is as correct as it can be.
Is it perfect? Perhaps not, but at least it as still quite highly automated and the core code (where most of the "magic" happens) still has pretty good coverage..
I would generally avoid testing that involves relying on UI elements. I favor integration testing, which tests everything from your database layer up to the view layer (but not the actual layout).
Try to start a test suite before writing a line of actual code in a new project, since it's harder to write tests later.
Choose carefully what you test - don't mindlessly write tests for everything. Sometimes it's a boring task, so don't make it harder. If you write too many tests, you risk abandoning that task under the weight of time-consuming maintenance.
Try to bundle as much functionality as possible into a single test. That way, if something goes wrong, the errors will propagate anyway. For example, if you have a digest-generating class - test the actual output, not every single helper function.
Don't trust yourself. Assume that you will always make mistakes, and so you write tests to make your life easier, not harder.
If you are not feeling good about writing tests, you are probably doing it wrong ;)
A common practice is to move all the code you can out of the codebehind and into an object you can test in isolation. Such code will usually follow the MVP or MVC design patterns. If you search on "Rhino Igloo" you will probably find the link to its Subversion repository. That code is worth a study, as it demonstrate one of the best MVP implementations on Web Forms that I have seen.
Your codebehind will, when following this pattern, do two things:
Transit all user actions to the presenter.
Render data provided by the presenter.
Unit testing the presenter should be trivial.
Update: Rhino Igloo can be found here: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/
There have been tries on getting Microsoft's free UI Automation (included in .NET Framework 3.0) to work with web applications (ASP.NET). A german company called Artiso happens to have written a blog entry that explains how to achieve that (link).
However, their blogpost also links an MSDN Webcasts that explains the UI Automation Framework with winforms and after I had a look at this, I noticed you need the AutomationId to get a reference to the respecting controls. However, in web applications, the controls do not have an AutomationId.
I asked Thomas Schissler (Artiso) about this and he explained that this was a major drawback on InternetExplorer. He referenced an older technology of Microsoft (MSAA) and was hoping himself that IE8 will do this better.
However, I was also giving Watin a try and it seems to work pretty well. I even liked Wax, which allows to implement simple testcases via Microsoft Excel worksheets.
Ivonna can unit test your views. I'd still recommend moving most of the code to other parts. However, some code just belongs there, like references to controls or control event handlers.