David Borchgrevink wrote:When I am populating the fields, instead of hardcoding 1 value in each, I'd like to set it up to be data driven through excel or MySQL (what word would I use to describe that? would robust be accurate there? or maybe versatile).
David Borchgrevink wrote:2. Also when populating the fields, that code looks cumbersome, and I'm trying to figure out a way I could use a loop to populate for each field, and what type of loop it would be?
David Borchgrevink wrote:3. Being new to automation (QA Engineer Level I intern), and testing in general, is there another/better method or tool to use if I wanted to stick with Java for automation? My job had me using QTP and VB Script, which was really powerful, for a little while to kind of introduce this to me, but I'd rather stick with Java because Java is where I want to focus (and they're giving me the option, so it's not like I'm being insubordinate with them)
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeanne Boyarsky wrote:David,
First of all, I've given you a cow for asking such a great question. It's clear, interesting and contains all the relevant information.
If I'm understanding the data you want to externalize right, I don't think you need the Parameterized Test Case pattern here. I recommend reading up on it anyway though. It's a good tool to have in your tool box.
That code does look cumbersome. One approach would be to have two arrays. One would contain the two "in" values and the other would contain the 20 "ex" values. Then you could use two for loops to create the field names with the right index and build the list that way.
You picked the best of breed tools.
I see two other things to remark on in your code:
1) The FirefoxDriver is a lot slower than the HtmlUnitDriver in Selenium. If you need to test in a real browser, you have to live with it. But if you are just testing functionality and a "simulated" browser does the job, it is worth considering.
2) In Java, we general throw Exception and not Throwable. The later includes system errors like running out of memory that automatically get thrown.
2) I see in a number of places that you catch an exception and print a stack trace. When this happens, you should fail the test and not proceed silently. You could add a fail statement. But it would be better to remove the try/catch block entirely and let JUnit deal with the error. Conveniently the default behavior is to fail the test and give you a stack trace!
David Borchgrevink wrote:That is a great idea. I feel like I was close to thinking of that, but I can't take the credit Quick question though, if I were to try and create a hypothetical framework for web app testing, I would have to know the html source for each element for each site tested ahead of time right? Because not every site will have id's or name's that are identical? Is there a way to make a "universal" method to do things like that? If not, meh whatever, but now I'm curious.
David Borchgrevink wrote:
2) I do realize that Exception would have been better (isn't best practice to use the most specific expected exception first, then work your way down to throwable or exception?). The only reason I kept the step definition class' method declarations like that was because Cucumber populates them automatically for you when you run the Feature file with no methods in the step definition file, and it was quick and easy to use.
David Borchgrevink wrote:
2)So if I'm understanding you correctly (again, I'm a newbie to all of this), just having the JUnit jar files added to the project will do that for me? That's great! I guess I added the try/catch blocks around each step definition after the fact because I thought it was good unit testing practice (I could very well be using that term incorrectly), but either way that is good to know
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |