Cedric Beust

author
+ Follow
since Oct 12, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Cedric Beust

Tomek is too modest to say it, but he recently authored a book called "Practical unit testing with TestNG and Mockito" which I strongly recommend. See his signature for the details.
11 years ago
No, but nothing stops you from having a data provider combine the results of several data providers and use that one in your @Test method.

12 years ago
You probably mean the creator of TestNG :-)
12 years ago
I am not aware of any incompatibility between JMockIt and TestNG, please let me know if you are having any problem and I'll be happy to take a look.

Le Fre: I'm not sure why you need to replace the testng.jar that comes with the Eclipse plug-in, this should definitely not be necessary. Feel free to email me directly (cedric@beust.com) if you'd like to give me more details.
13 years ago
Jeanne,

Just because this feature exists doesn't mean you have to use it.

Besides, when you embark on picking a testing framework, it's very likely that you will be using it to do both unit *and* functional testing. For the latter, dependencies can be useful, especially if you're using Selenium or doing some web testing. Check out the Selenium forums to understand how people use TestNG's dependencies to simplify their tests.

As for your 3), it does sound like a hack to me. You created a workaround for the fact that JUnit doesn't support @BeforeSuite and @AfterSuite. It doesn't scream "great design" to me :-)

Le: happy to answer your questions about TestNG, feel free to ask here or on the testng-users mailing-list.

--
Cédric

13 years ago
View#getWidth() won't give you a meaningful answer until the view has been measured, and when it does, it still doesn't give you the width of the display, which is what I believe the original poster was asking.

Here's how you do it:

Display display = ((WindowManager) getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay();
int width = display.getWidth();

--
Cedric
Android engineer
15 years ago
Hi Pradip,

Originally posted by Pradip Bhat:
Like you said if there are 1000 records and 850th record cause the test to fail does, TestNg print the offending record or just would say that test fail ? Thanks


The report tells you exactly which parameters were used for each invocation, so it's trivial to find out exactly which data set caused the test to fail.

--
Cedric
16 years ago

Originally posted by Pradip Bhat:
If we are doing TTD wouldn't there be many broken tests because the features are still not implemented.


Yes, although you usually don't commit anything until you have tests that don't break (even if it means they're still empty or not testing much yet).

Having said that, I still confess a certain skepticism toward TDD, which you will find echoed in the book.

While I agree that TDD is a good practice to make someone more aware of what "testable code" is (if they have to write the tests first, they will be forced to make their code testable), I am still concerned that the "dark side" of TDD is hardly ever brought up by its proponents.

Some of the problems I see with TDD are:

- It's not intuitive. This is not necessarily a bad thing, but it's not always easy to ask developers to do something against their training.

- It forces you to spend a lot of time with broken code. By definition, you write a lot of code that at first doesn't even compile and then, invokes code that is empty. Doing that basically means you are foregoing a lot of the powerful features that IDE's offer (automatic completion, browsing, etc...) since IDE's do very poorly with files that don't compile.

- It's sometimes much less practical than testing last (try doing TDD on graphical user interfaces or mobile phones).

- It can generate a lot of churn (testing code that is quickly going to be scrapped and replaced).

- I haven't seen any evidence that in the hands of an experienced developer, code that is written test first is necessary of better quality than code written test last.

- TDD tends to promote micro-design (designing at the method level) over macro-design (thinking ahead of time about a class hierarchy and starting to implement it even though it might not be needed at this early stage).

- It can make developers oblivious to the fact that the code they are writing is for users and not for themselves.

There is much more to say on this subject and we dive into more details in our book, but overall, I tend to recommend to learn about TDD but consider it like a tool that can *sometimes* (but not always) lead to better code.

Testing first or testing last doesn't matter too much as long as you do write tests.

--
Cedric
16 years ago
Hi Prad,

Originally posted by Prad Bhat:
How do I use TestNg for integration testing ? Is there any guideline on this ?



A big portion of our book is dedicated to integration testing. Here are a couple of features that are built natively into TestNG that make integration testing very easy:

- A straightforward API that lets you create and configure a full TestNG runner inside the container (i.e. on the server side) so that you can run tests on your actual logic instead of having to mock it on the client side.

- Dependency testing. With this feature, you can specify that your tests should be run in a certain order ("don't run the servlet tests unless all the database tests have passed").

There are over a hundred pages in the book dedicated to integration and enterprise testing alone, so we cover a lot of this area...

Hope this answers your question.

--
Cedric
16 years ago
Imagine that getData() returns a thousand different data sets. You want to have a thousand tests invoked, each with one set, not one test that tests one thousand different test cases...

--
Cedric


Originally posted by Pradip Bhat:
With reference to this interview of C�dric Beust

http://www.artima.com/lejava/articles/testng.html

I have question regarding dataProvider on whether we really need it ?

How is writing
different from

16 years ago
@BeforeMethod is invoked before each method, so you have the following invocations:

beforeMethod
test1
beforeMethod
test2
...

If your beforeMethod fails, it's likely to fail for all subsequent invocations, so I think it's safer to mark all the test methods skipped so the user will focus on the main problem: investigating why beforeMethod is failing.

--
Cedric


Originally posted by Jeanne Boyarsky:

Not yet. I understand that explanation for @BeforeClass - if the classwide setup fails, it doesn't make sense to do anything in that class.

@BeforeMethod is just for one test method though, right? So why would one method's setup pertain to the entire class? For that matter, why is it invoked "before all the methods of the class"? It's method specific.

Suppose I have the following test method in JUnit:

Converting it to TestNG, I would have:


In the JUnit example, I expect all other tests in the class to run because the setup that failed was inside a particular test. Why would the TestNG example work differently? If I had something that affected the whole class, it would go in @BeforeClass, no?

16 years ago
Hi Swosti,

Originally posted by Swosti Dipan Pal:
How the new generation testing id different from the current approach of Junit and Load/Regression testing ?

What are the advantages of using these approaches ?

Who are the audiences for these testing ?



We have covered quite a few topics addressing this question in the other threads, can you take a look and then let us know if you have specific questions?

--
Cedric
16 years ago
Hi Jeanne,

Originally posted by Jeanne Boyarsky:
My last question of the week:
On page 112 of "Next Generation Java Testing - TestNG and Advanced Concepts", it says that if @BeforeMethod fails, all test methods in the test class are skipped. Why does TestNG skip all the methods rather than just the one method the @BeforeMethod goes with?



The @BeforeMethod is invoked before all the methods of the class, so it doesn't make sense to run any of these if it's failing, because it's probably going to fail for all of them...

Makes sense?

--
Cedric
16 years ago
Hi Andrew,

You can easily pass parameters to your test methods with TestNG's Data Providers, which I described in this thread:

https://coderanch.com/t/96288/Testing/most-important-feature-TestNG

Once you can pass parameters to your test methods, nothing stops you from overloading the same method name several times with different signatures...

--
Cedric
16 years ago
Hi Jeanne,

Originally posted by Jeanne Boyarsky:
I'm curious what the authors (or anyone else with experience in TestNG) consider to be the most important few features in TestNG that is not in JUnit 4.0. Most articles, just hash through the differences between TestNG and JUnit 3.8.

From reading the book, the concurrency testing support seems useful if you are working on a threaded application.

If test groups are your answer, what do you consider the second most important feature that is not in JUnit 4.0? (because groups have been well discussed this week)



Since you excluded groups, I'll have to name Data Providers as my favorite feature #2, and it seems to be a feeling widely shared by TestNG users.

For readers not familiar with Data Providers, here is an example:

@DataProvider
public Object[][] data() {
return new Object[][] {
new Object[] { "Lexus", "Red" },
new Object[] { "Toyota", "Blue" },
}
}

@Test(dataProvider = "data")
public void verifyMakeAndColor(String carModel, String color) {
// will be invoked first with ("Lexus", "Red") and then with
// ("Toyota", "Blue")
}

This simple construct allows you to define all kind of interesting tests where the business logic of your test doesn't change but the data does.

Since the Data Provider is a Java method, it can get its data either directly from the source (as shown above) or from many different locations: properties file, flat file, XML file, Excel spreadsheet (very popular), a database or even the network.

TestNG users have been extremely creative over the years with this feature. For example, someone posted the code for a Data Provider that would read a configuration file based on the test method it's about to feed data to, which I found very clever.

We have an entire section on Data Provider in the book and we have barely scratched the surface of what it can do...

Does this answer your question?

--
Cedric
16 years ago