How to filter unit tests from query?

[Hebi Li]

Dear All:

I want to get java projects with assertions which don’t belong to unit test code. There are two approach in my mind:

• filter filename
• filter method name

For the first method, I can get changed file name for every revision, which is not very helpful because the code will run for every version of the repo, and the changed files may be overlapped, resulting in scanning on the same file again and again.

To filter the method name, I use this job
which gives me empty output. Then I use another job, in which I commented out the if (m.statements[i].kind == StatementKind.ASSERT). This job did give me results, and when I manually choose the project ControlTier from the output, I found actually the method testXXX did contain several assertions. That implies the first job should have given me some output.

Any help would be appreciated!

Thanks,
Hebi

[Hridesh Rajan]

Hi Hebi,

Welcome to the Boa forum. We are glad that you have decided to use Boa for your research. With respect to your question following post may be helpful. 

https://groups.google.com/d/msg/boa-user/bxH8lDldL10/AJM5roN3FdgJ

I think what you are trying to do is the reverse of the query above. Other Boa users have tried similar queries and they may also be able to help you on this matter.

Also, looking for imported junit library might also help. You could include the following before clause in your visitor that will stop your current visit. 

before node: ASTRoot -> {

exists(importIndex : int; match("^org\\.junit",node.imports[importIndex]))

stop;

}

Hope that helps. Let us know if you have any further questions. Thanks!

Best wishes, 

- Hridesh

Dr. Hridesh Rajan

Dept. of Computer Science, Iowa State University

http://www.cs.iastate.edu/~hridesh/

My Lab: http://design.cs.iastate.edu

[Hoan Nguyen]

Hi Hebi,

For getting assert statements, do not use field Method.statements for now.

Instead, use these two steps:

  1. Filter the method you are not interested in based on names

        before m: Method -> {

   if (!match(`^test.*`, m.name)) {

        stop;

   }

}

  2. Get the assert

before node: Statement -> {

    if (node.kind == StatementKind.ASSERT)

        total++;

}

Hope this helps.

[Robert E Dyer]

Hi Hebi,

I see a few issues with this query.  Let me go over them and see if I can help you.

1) you are scanning m.statements to look for assert statements.  However, this would not find asserts that are nested further down (say inside an if statement, or a loop) because you are only scanning the top-level statements that appear directly inside the method body.  What you need instead is to *visit* those statements and look for asserts.  This appears to be the code you commented out.

2) the match call in your method visit seems to be wrong - this will match only methods that *are* unit tests (in JUnit 3) - this needs to be negated

3) as Hridesh pointed to you, JUnit 4 doesn’t require methods be named ‘testXXX’ and instead uses an annotation

4) because of #1 you really need to keep a stack for your total variable

Here is my version of your query, keeping those in mind:

http://boa.cs.iastate.edu/boa/?q=boa/job/public/9933

You can see it has a lot of output.  I randomly checked a few and they seem ok to me.

Let me know if this helps or not!

- Robert

--
You received this message because you are subscribed to the Google Groups "Boa Language and Infrastructure User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to boa-user+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

________________________________________________

Robert Dyer | Assistant Professor | Department of Computer Science
BGSU | rd...@bgsu.edu | 419.372.3469 | 238 Hayes | Bowling Green, OH

Want to mine ultra-large-scale software repositories with minimal initial

investment? Check out Boa! http://boa.cs.iastate.edu/

[Hebi Li]

Hi Dr. Rajan, Hoan, and Dr. Dyer,

Thank you so much! That result is perfect for me. All of your explanations make a lot of sense.

Regards,

Hebi