Can I test my client side GWT code without GWTTestCase? I've heard somewhere (I think it was one of the Google IO 2009 conferences) that they were successfully testing their code with a fake DOM, in the JVM and not in Javascript with the DOM. That would be brilliant. The point of this would be to gain speed (order of magnitude). Does anybody have any idea about how to do this? My first question on stack overflow, hope I'm doing this right.
Thanks.
Eugen.
You should check out the Google I/O session by Ray Ryan.
Basically, you can use the Model/View/Presenter pattern and abstract away all the DOM-accessing code to the 'View' portion. By doing this, you can create a mock view and test the model/presenter using standard junit tests, running via the jvm, without the need for a browser or a DOM
Not quite what you're looking for, but you should use the Model-View-Presenter pattern. Any code that requires the DOM should go in your View classes, and should be as dumb as possible. Complex logic goes in your Presenter classes. You can then test your presenter classes without needing a GWTTestCase.
E.g, a view might have a method like:
void setResponseText(String text);
Your presenter test case can then look something like:
void testSayHi() {
expect(mockView.setResponseText("hi there"));
replayMocks();
presenter.sayHi();
verifyMocks();
}
Related
Soo I'm developing a game with the Godot engine and I want to create some test for the code to be sure that everything is working, I can't test the game with simple actions it takes 5-10 minutes. Is there a way to write tests ???
Have a look at GUT, the Godot unit test framework, or WAT.
Differences between the two, quoting WAT's author:
GUT runs in a scene. WAT runs in the editor itself.
GUT (last I checked) cannot handle creating Test Doubles that take constructor dependencies (as in it uses the _init method with
arguments).
WAT has parameterized testing (so you can do the same test multiple times only needing to define the different set of arguments per run
through).
WAT has a much larger range of asserts (I think)
WAT can intentionally crash a test script if one method fails (this isn't documented yet though).
WAT cleans up after itself with regards to memory. GUT doesn't. (Note: This was largely thanks to the recent method print_stray_nodes
builtin to Godot that GUT didn't have during its initial creation).
GUT allows for inner test classes. WAT doesn't. However WAT has the "context" attribute attached to every asserts call so you can add
sub-context to your describe() method context of the parent method.
There is also GdUnit3 https://github.com/MikeSchulze/gdUnit3 ;)
It will release in upcoming version 2.0.0 with c#-beta support.
GdUnit3 is full integrated in the Godot editor with a UI inspector to navigate over your test results.
Supports also automated testing by using the command line tool in a Github-Action
Feel free to give a try ;)
I would like to know the best design pattern for Selenium for automating large scale SaaS Product.
Looking for all your comments on this.
and for large scale application i preferred keeping my xpath's for web elements in page object file. but my lead wants me to keep xpath's in Properties file and we should access Properties file for every xpath's. Is this a good approach of keeping xpath's in properties file for Large Scale SaaS application?
Your leed wants you to implement Object Repository Pattern.
I think this idea is as old as HP QTP (QuickTest Professional) where it is extensively used - but I may be wrong, it's only my opinion.
In short (a quote from the above link):
Object Repository is a centralized location where we can store objects
information, it acts as interface between Test script and application
in order to identify the objects during the execution.
We always recommend using external file for object repository rather than hard coding the objects and its properties
directly into our code. If you are asking me why this is? Reason is as
it reduces the maintenance effort and provides positive ROI, for
example say any of the object properties change within our application
under test, we can easily change it in external object repository
file, rather than searching and doing updates for that object
individually in the code
Think of a scenario where you have a Webpage and it has multiple
sections, multiple frames and hundreds of WebElements. Obviously you
do not want that once you type the page name and it will give you all
the elements available on the webpage. If there are few elements, it
is fine to have the same structure but if there are many then it is
advisable to divide your page in to different sections for e.g.
header, footer, left navigation, center content and right navigation.
Then categories each WebElement under their parent element.
I think this pattern does not stand in contradiction to the Page Object Pattern, they can both work very well together. It brings greater transparency to the project and forces developers/testers to maintain better readability of the project, which helps in maintaining it in the future.
But the above is only a bit of theory, one may ask how this pattern can help in real life?
Consider a simple example. Let say that there is a piece of code:
public class SomePageObject{
.....
.....
public void doSomething(String value){
findElement( By.xpath("//*[ #class='left-content']//button[ contains( ., 'list-selector' )]") ).click();
wait.until( ExpectedConditions.visibilityOfElementLocated( By.xpath( String.format( "//li[ *[ text() = '%s' ]]", value ))).click();
}
I have seen code like this hundred of times. What do you think about this code ? Yes, it follows the well known Page Object Pattern. But it is horrible.
Looking at this code, can you guess what is it doing? Definitelly No.
What error message will you get in the log when this code will break due to change in UI of second element ? Most likely something like this:
org.openqa.selenium.TimeoutException: Timed out after 30 seconds
waiting for visibility of element located by By.selector: //li[ *[ text() = 'New York' ]]
Can you guess, looking only at this error message, which part of the application it concerns and where it can be found in the code ? No.
An automation engineer can find it in code looking at stack trace but a junior tester who doesn't know java, selenium etc. cannot fix it looking only on the error and a printscreen (if available).
In many cases in order to fix the error, the automation engineer needs to run this test case on a local machine to replicate the issue.
How can it look like using Object Repository Pattern ?
There can be a property file which may look like this:
....
orderPage.citySelectButton=//*[ #class='left-content']//button[ contains( ., 'list-selector' )]
orderPage.citySelectListElement=//li[ *[ text() = '%s' ]]
...
...
and a code which may look like this:
public class SomePageObject{
.....
.....
public void doSomething(String value){
objRepoFacade( "orderPage.citySelectButton" ).click();
objRepoFacade( "orderPage.citySelectListElement", value ).wait().click();
...
)
}
The error message in the log may look like this:
RuntimeException: time out waiting for element: orderPage.citySelectListElement
located by By.selector: //li[ *[ text() = 'New York' ]]
And now even the junior tester, looking only on this error message, is able to easily guess in which part of the application the error occurred, and which exactly element is broken. The tester may be trained how to inspect an element on the page using the developer console (F12), correct the selector in the procerties file, and fix the issue on his own without the help of automation engineer and without touching the code at all.
Preasumbly from your leed's point of view the latter (Object repository) is a better solution because it can employ more junior testers and fewer automation engineers and reduce costs.
I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.
I am a manual tester trying to learn GEB and Spock. To learn these do I have to have prior knowledge of java or groovy? I have been reading the book of GEB, What are the prerequisites, books or learning resources? Please help. Thanks.
I tried compiling some essentials and some 'good-to-haves' that I found very helpful when I picked up Geb.
Some Groovy Magic. Most of all that you need to learn Groovy is covered in this manual but for obvious reasons if you get obsessed with the language you might want to consider Groovy in Action. While Java is not needed to pick up Groovy, If you are from a Java (except for closures) or even a Python background, you could probably skim through the tutorial for 15 minutes and you are there already).
A little Selenium. The more, the better but fear not, this single page tells you all that you need to know about the Selenium Webdriver that you would generally use. But to stress, the more the better.
jQuery selectors (everybody says that it is easy but frankly, I refer to the manual at least twice per hour. I am dumb, so…). If you are new to jQuery, you would want to start from basic selectors and click on the left navigation menu for more. Please note that not all jQuery selectors are applicable for Geb but the selectors section of Geb tutorial wasn't very exhaustive and engaging.
At the end of my testcases, I need to generate a fanciful report which stretches across multiple testcases and I had dependencies among testcases. So, I went for TestNG instead of Spock. Frankly, I didn't give Spock a lot of chance.
PageObjects is actually not a prerequisite for Geb but PageObjects are so awesome that you never wanted to think about Geb outside of it. PageObjects is a cute little pattern which says that you wrap the structure of your HTML page into an Object so that the actual test does not have to deal with it. Hah. Got you. Let me put that in plain English.
Say, you have a registration form with input textbox which has an id of "nametext". How would you get the handle of the textbox? In DOM terms, in javascript, you would just do a
document.getElementById("nametext")
In Selenium, you would do a very similar thing
driver.findElement(By.id("nametext"))
So, if you would want to populate Jason in your text box in Selenium, you would do a
driver.findElement(By.id("nametext")).sendKeys("Jason");
If you do that for all your input fields, very soon your testcases become ugly and hateful. Instead of that, in OO terms, you encapsulate. You create a new class, say RegistrationPage and wrap your findElement and sendKeys as in :
public class RegistrationPage{
…
public RegistrationPage fillRegistrationForm(String name, String email){
driver.findElement(By.id("nametext")).sendKeys(name);
driver.findElement(By.id("emailtext")).sendKeys(email);
}
}
and from your testcase, you would say
RegistrationPage regPage=new RegistrationPage();
regPage.fillRegistrationForm("Jason","jason#bourne.com");
(Even better idea is to wrap your input values into a class and pass it to the fillRegistrationForm)
In fact, Geb leverages PageObjects in a much better way - jQuery selectors to the rescue
class InputFormPage extends Page{
…
static content={
name {$("input", id:"entry_0")}
emailAddress {$("input", id:"entry_1")}
}
}
and in your testcase, you would just say
name.value ("Jason")
emailAddress.value ("jason#bourne.com")
My situation, as some background:
I'm writing a small javascript library which uses window.requestAnimationFrame to perform its animation loop. Because that function isn't standardised across the browsers yet, internally in the library it creates a polyfill-ish function in a closure.
var requestAnim = window.requestAnimationFrame
|| window.webkitRequestAnimationFrame
|| ...
|| function () { ... };
The issue here is that this makes it quite hard for me to test this code now. Previously, when it was using setTimeout, I would override that global function in the tests to simulate a number of frames passing synchronously.
Anyway, to the point of the question:
Right now, it seems like my options are either to leave some of my code untested, or to add extraneous features to the library with the sole purpose of making it easier to test. Neither of these options sound that great to me.
Without worrying too much about my specific case, in general, what should you do in this situation?
Yes, it is ok.
We don't write tests for the sake of testing. Testing is an acknowledgement of the fact that we aren't brillant enough to write and maintain code perfectly without safety checks. All test code serves one purpose and only one: to make a better product. This is true whether it lives in the /test folder or in the /src folder. Therefore it is a mistake to think "This is never called in production, therefore it is wrong to put it into /src!"
To be sure, there are other trade-offs to make, e.g. size (in an embedded product it makes a lot of sense to try everything you can to keep the /src folder small). But that is a completely different reason than merely "It's test-related".
I'd say it's fine to add testing code (unless some micro-optimisation is something you're testing). As Kilian was saying, nobody is perfect; this is the reason we do testing in the first place.
I +1d Kilian's answer, but I'd like to add my own ideas too:
In general, what situations would there be code that you cannot (with ease) test? This would be code that only runs under conditions, which you can't re-create on your testing machine? Perhaps it would be easier to set a variable to decide whether this code should run or not, then you can set a breakpoint and change this variable when debugging (in your JavaScript case, using Firebug or Chrome's developer tools?)
Or, like you say, add some testing code - a set of flags maybe at the top of the script, to keep it neat? Then your if statements could be something like
if(shouldRunThisCode || isTestingThisCode) {
doThisCode();
}
In short: Ofcourse it's fine to add code for the purpose of testing. I can't think of any scenarios where testing the code will require adding much code at all though. If the code is implemented and intended to run at some point under certain conditions anyway, it can never be too hard to test.
In general, code that is hard to test is badly written.1 It is superior to find the design problems your test difficulties are telling you about and fix those than to add code "just to make testing easier". Sometimes we do that anyway, because we construe the design problems as too difficult to fix -- but it should be the second choice. In your case, it sounds like the bad design you're exposing is in a library outside your control. In this case, adding code "just to make testing easier" is probably the best choice; you are unlikely to have enough control over an external library to improve its design.