Web Application Tests Visualization [closed] - firefox

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I'm testing a web application with several functionalities. I didn't develop this application, I'm a mere tester. I'm new to testing and when I started working on it I was given a series a Selenium Tests. These tests are performed by using Selenium IDE on Firefox.
They're very easy to perform in this way, cause you can just record and store variables and run the test.
The problem is that when, for example:
* a web page has a table with 3 rows, I prepare the test for this scenario, it works
* the day after the table has 4 rows so my test doesn't work anymore,
* Selenium doesn't allow me to make a for-cycle over rows or columns
That's why I thought I could export the several Selenium test to Java 4 Web Driver and import them in Eclipse. In this way I'm able to improve the code, by adding for cycles and other stuff.
I created a project for my test suite, imported the JUnit 4 and Selenium library, ran the suite and everything was alright, no errors. It was great.
*The thing is: how I do I manage to VISUALIZE (or Playback) on Firefox Browser my tests, as I was doing earlier in Selenium IDE?? *
Thx a lot

When you run the tests in Eclipse, it will open a Firefox window and perform the tests just as it would in the IDE.
As for actual test management (i.e starting/stopping tests) you will need to invest in some CI software. TeamCity, Jenkins or something like that will work.
As for picking elements out (the 'find' option in Selenium IDE), this is much more tricky as you've just ditched the IDE and are very new to Selenium. It is, however, easily done.
You can run XPath and CSS queries directly into Firefox's Console (or Firebug, if you wish). Thus, you can still run the same queries you would in the IDE, the only difference is how the results are returned to. Selenium IDE will 'highlight' an element, whereas the console will return it as a DOM object.
If none of the above helps, please go into more detail for what you are requiring, but I've covered what the IDE allows you to do and what are the alternatives.

Related

GUI testing coverage

I have two questions. My first question is: Do applications exist which measure the coverage of GUI testing for web applications (not code, but the coverage of GUI components on web page)?
My second question is:
Is GUI testing with Selenium for example necessary if we have tests for javascript as well?
Thank you in advance.
You can write your custom application to find all dom elements using http://www.w3schools.com/js/js_htmldom_elements.asp, store this in some place and after completing your test automation framework run this utility to make sure that none of the elements are missing.
GUI test is required to make sure that all your integration points b/w several backend API are working. Also we will be sure that non of the UI elements are break over UI and all your business use cases are working as expected. Mostly UI testing is done for Acceptance Testing and we can show to the customer that all there use cases are working as expected. Later in the next release you can make sure that you are not breaking any UI code. UI testing gives us confidence while releasing to end users.

how to quickly migrate a project to Xcode? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
The previous project was developed on Linux platform, which I plan to move to Xcode IDE.
Other things aside, I want to know how to quickly set up the project in Xcode.
Ideally, it should just take the top-most Makefile and carry out automatically (e.g. indexing, auto-completion, jump to definition etc.). For Eclipse, it is pretty much like that. But I could not find similar functionality in Xcode (not expert as you can tell).
Really appreciate your help.
There is no way to "import" the makefile into an Xcode project, but you can make Xcode run your makefile for you by using an external build tool. When you create your project, choose the Other category under Mac OS X, then choose External Build Tool and click the Next button. The next screen will have a text field at the bottom which allows you to enter the command to run. Make sure it is /usr/bin/make. Then, finish creating your project. Now, whenever you build, Xcode will run make from the project directory.
Note that this is not a "native" Xcode project, so you will have to do more manually. For example, you are still responsible for updating the makefile when you add/remove files, and the build settings in Xcode will be ignored unless you customize your makefile to use them. If you want to do more than build from Xcode, you will also have to edit your scheme and set up the other actions, such as specifying the executable for running.
Even though the external build tool option is not available in the iOS categories, you can use the Mac OS X version, since your makefile defines what gets built. I don't know if Xcode will attempt to analyze/complete your code, but you may want to update your SDK and target version settings, just in case.

TDD & BDD? Which, Why and How? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
TDD & BDD? Which, Why and How?
Can anyone give a good explanation to justify "Which", "Why" and "How" on both?
Thanks in advance.
TDD is used more for unit testing e.g. testing a method on a class. BDD is used for testing the behaviour of a system e.g. Creating a user, or Sending out new product emails.
So for TDD you might see something like.
public void Test()
{
// Arrange.
var sut = new ClassToTest();
// Act.
int result = sut.SoSomething();
// Assert.
Assert.Equal(result, 23);
}
With BDD (depending on the tools you're using) you tend to see something like this:
Feature: Add a user
As a system admin
In order to give a user access to the site
I want to create a user account
Scenario: Creating a basic user
Given I have the user's name
When I create a new user account
Then that user can log onto the site
As you can, BDD is testing the behaviour of a system rather then single unit. Here is a very good intro to BDD by Dan North - http://dannorth.net/introducing-bdd/
I would recommend using TDD when you are building your classes/code and want to testing little bits of it at a time. Use BDD when you want to test more then one of those classes in a test i.e. integration test.
EDIT:
With the how side of things, for BDD I would recommend using SpecFlow. This is a popular BDD tool which adds a lot of functionality to Visual Studio for creating feature files (The Feature: stuff I mentioned above) and running and debugging the tests.
Under the hood SpecFlow can use NUnit or MSTest to generate the tests. Other BDD tools include:
MSpec
NSpec
SpecsFor
StoryQ
and many others I've forgotten about right now :) I would suggest you try them out and see which one you prefer.
For TDD you have many options including:
NUNit
xUnit
MSTest
A lot of the above tools can installed via NuGet in Visual Studio, which is handy.

How to treat future requirements in terms of TDD [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
While attempting to adopt more TDD practices lately on a project I've run into to a situation regarding tests that cover future requirements which has me curious about how others are solving this problem.
Say for example I'm developing an application called SuperUberReporting and the current release is 1.4. As I'm developing features which are to be included in SuperUberReporting 1.5 I write a test for a new file export feature that will allow exporting report results to a CSV file. While writing that test it occurs to me that the feature to support exports to some other formats are slated for later versions 1.6, 1.7, and 1.9 which are documented in a issue tracking software. Now the question that I'm faced with is whether I should write up tests for these other formats or should I wait until I actually implement those features? This question hits at something a bit more fundamental about TDD which I would like to ask more broadly.
Can/should tests be written up front as soon as requirements are known or should the degree of stability of the requirements somehow determine whether a test should be written or not?
More generally, how far in advance should tests be written? Is it OK to write a test that will fail for two years until the that feature is slated to be implemented? If so then how would one organize their tests to separate tests that are required to pass versus those that are not yet required to pass? I'm currently using NUnit for a .NET project so I don't mind specifics since they may better demonstrate how to accomplish such organization.
If you're doing TDD properly, you will have a continuous integration server (something like Cruise Control or TeamCity or TFS) that builds your code and runs all your tests every time you check in. If any tests fail, the build fails.
So no, you don't go writing tests in advance. You write tests for what you're working on today, and you check in when they pass.
Failing tests are noise. If you have failing tests that you know fail, it will be much harder for you to notice that another (legitimate) failure has snuck in. If you strive to always have all your tests pass, then even one failing test is a big warning sign -- it tells you it's time to drop everything and fix that bug. But if you always say "oh, it's fine, we always have a few hundred failing tests", then when real bugs slip in, you don't notice. You're negating the primary benefit of having tests.
Besides, it's silly to write tests now for something you won't work on for years. You're delaying the stuff you should be working on now, and you're wasting work if those future features get cut.
I don't have a lot of experience with TDD (just started recently), but I think while practicing TDD, tests and actual code go together. Remember Red-Green-Refactor. So I would write just enough tests to cover my current functionality. Writing tests upfront for future requirements might not be a good idea.
Maybe someone with more experience can provide a better perspective.
Tests for future functionality can exist (I have BDD specs for things I'll implement later), but should either (a) not be run, or (b) run as non-error "pending" tests.
The system isn't expected to make them pass (yet): they're not valid tests, and should not stand as a valid indication of system functionality.

Joomla 1.5 basics [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am a beginner to Joomla 1.5 ... I have read about the structure and how to build Modules, Components and plugins... But I don't know when to build those and when to use those...
Can anyone shed light on this?
Components are sort of web applications developed using the joomla framework. They are displayed in the main content area of a joomla site (just as articles, which are displayed by the content component). The component usually has its own administration backend accessed through the "Components" menu.
Modules are rendered as little blocks of html which can be shown in different module positions (usually in the sidebar). On stackoverflow the "upgrade your career today" widget on the right is a good aproximation of what a module is in Joomla. In a standard installation of joomla a login box is an example of a module, so is the menu.
A plugin is used to do some internal work behind the scenes. It is basically an event observer, which is activated when some event is raised inside the core joomla framework. A good example is an email cloak plugin from the core of Joomla which is invoked when the article is rendered and substitutes email addresses inside an article with some javascript to help protect them from spammers.
Content plugins are just one example. Recently I developed a plugin which logs every successful login attempt in a database. It was done by handling the event raised when a user logs in to the site.
You build a module or plugin or anything else when you don't find one which complete you needs. Before develop be sure that nothing exist.

Resources