Chisel: How to wait for signal assertion in ChiselScalatestTester? - chisel

I want to create a testbench for my Chisel-based module. So I'm using ChiselScalatestTester to create the testbench. My module use a custom protocol to communicate with the outside world. So inside the test class I have to wait for some signals to be asserted from DUT. Here is an example from my test class:
...
while (dut.io.outBusy) {
dut.clock.step()
}
...
Would someone please help me implement this?

Looks like you almost have it. Try
...
while (dut.io.outBusy.peek().litToBoolean) {
dut.clock.step()
}
...

Related

Jodd proxy Unable to install breakpoint due to missing line number attributes

I have a jodd project that uses Proxetta and JTX for creating transactions over services classes. The issue is that when I try to debug a service class I receive :
Unable to install breakpoint due to missing line number attributes
I suspect that there has something to do with they way Proxetta generates my proxies classes as it seems that in Spring if you have no interface for a class the same happens.
I use Eclispe and here how Proxetta is initialized:
public void initProxetta() {
ProxyAspect txServiceProxy = new ProxyAspect(AnnotationTxAdvice.class,
new MethodAnnotationPointcut(Transaction.class) {
#Override
public boolean apply(MethodInfo mi) {
return isPublic(mi) &&
isTopLevelMethod(mi) &&
matchClassName(mi, "*ServiceImpl") &&
super.apply(mi);
}
});
proxetta = ProxyProxetta.withAspects(txServiceProxy);
proxetta.setClassLoader(this.getClass().getClassLoader());
}
Would you please try the following quickstart webapp1 example?
Its gradle project, so you can quickly import it in any IDE. In this example, we create proxy almost exactly like you above, but on actions (which should not make a difference). Now try to put a breakpoint into the IndexAction - this one gets proxified, for example. I am able to put break point there in IntelliJ IDEA.
Moreover, I dunno why Eclipse complains about the breakpoint in the service implementation class, since Proxetta as you used above creates a proxy subclass, and does not change the target class in any way. So when you put breakpoint in the service implementation code, it is in your class, not proxy class.
Finally, did you put BP on the method, or inside the code? If it is the first (on the method), then please try to put the BP inside the code of your service: eg on first line of the method body.

Don't let test stop on failure

I'm looking for the best practice for following (simplified) scenario:
#Test
public void someTest() {
for(String someText : someTexts) {
Assert.true(checkForValidity(someText));
}
}
This test iterates through x-thousands of texts and in this case I don't want it to be stopped for each failure. I want the errors to be buffered and in case of error(s) to fail at the end. Has JUnit got something on board for for my aim?
First of all, it's not really the correct way to implement this. JUnit allows parametrizing tests by defining a collection of inputs/outputs with the Parametrized test runner. Doing it this way ensures that each test case becomes a unique instance, making test report clearly state which samples passed and which ones failed.
If you still insist on doing it your way you should have a look at AssertJ's Soft Assertions which allow "swallowing" individual assertion failures, accumulating them and only reporting after the test is finished. The linked documentation section uses a nice example and is definitely worth reading.

POX component listen to events

I want to discover the topology of a network emulated by mininet using POX components. I figured out that I need to write my own component, which is listening to LinkEvents. Something like:
someObject.addListenerByName("LinkEvent", someFunction)
But I don't actually know on what kind of an object i should execute this.
If I execute it as
core.openflow_discovery.addListenerByName("LinkEvent", someFunction)
as stated in the openflow.discovery module, it throws the following error:
AttributeError: 'openflow_discovery' not registered
It is easier to use pox modules named "gephi" to do this, it should be under misc directory, just add this method to the "gephi_topo.py" in "class GephiTopo":
def get_gephi_topology (self):
switchesAndLinksAndHosts=[self.switches,self.links, self.hosts]
return switchesAndLinksAndHosts
and then use it anywhere in your pox controller like:
topo=gephi_topo.GephiTopo.get_gephi_topology(core.GephiTopo)
switches= topo[0]
links=topo[1]
hosts=topo[2]
Fixed it by calling addListenerByName from within launch().

How can you unit test Apache Cache Timer routes?

Using Apache Camel 2.9.1
How do I unit test something like the following?
public class MyRoute extends RouteBuilder {
#Override
public void configure() throws Exception {
from("timer.something?delay=0?repeatCount=1")
// do some stuff
.to("{{some.endpoint}}")
.end()
from("timer.somethingelse?delay=3000&period=1000")
// do some stuff
.to("{{some.other.endpoint}}")
.end
}
}
What is exactly that you want to unit test here?
Because it's clueless to unit test the timer component (I mean to unit test if it's triggered or not; and if its properties works as it should be): Camel team has done that already.
What is logical to unit test here is the "// do some stuff" part, which you'd do by mocking the endpoints. Your first route will be fired automaticly, while the second will with initial delay. You'll have to wait that much at least to assert anything. In these kind of cases I usually read the endpoint properties from a properties files like
from("timer:somethingelse?{{2nd.timer.properties}}")
and that can be set to
2nd.timer.properties=delay=3000&period=1000 //in prod
2nd.timer.properties=delay=0 //during tests
So that one is triggered at startup as well. Hope that helps,
Gergely
You can also use advice with in your unit test, and replace the from endpoint uri in the route during testing, and for example use a direct endpoint, then you can send a message to the direct endpoint to trigger the route to run.
See details at the Camel docs about testing
http://camel.apache.org/testing
http://camel.apache.org/advicewith.html
And there is also NotifyBuilder which can be used for "black box testing" where you may assert that X messages was processed etc
http://camel.apache.org/notifybuilder.html

How do I unit test a Grails service that uses a converter?

I have a Grails service that sends out e-mails using a 3rd-party service by doing a HTTP call:
class EmailService {
def sendEmail(values) {
def valueJson = values as JSON
... // does HTTP call to 3rd party service
}
}
I've written a unit test to test this service (because an integration test spins up Hibernate and the entire domain framework, which I don't need):
#TestFor(EmailService)
class EmailServiceTests {
void testEmailServiceWorks() {
def values = [test: 'test', test2: 'test2']
service.sendEmail(values)
}
}
However, when I execute this unit test, it fails with this exception when it tries to do the as JSON conversion:
org.apache.commons.lang.UnhandledException: org.codehaus.groovy.grails.web.converters.exceptions.ConverterException: Unconvertable Object of class: java.util.LinkedHashMap
I then re-wrote my unit test to just do the following:
void testEmailServiceWorks() {
def value = [test: 'test', test2: 'test2']
def valueJson = value as JSON
}
And I get the same exception when it tries to do the as JSON conversion.
Does anyone know why I'm getting this exception, and how I can fix it?
Even though you are testing a service, you can apply the #TestMixin(ControllerUnitTestMixin) annotation to your test class to get Grails to set up the JSON converter.
The as JSON magic is created when the domain framework spins up.
You have to either change your test to an integration one or mock the asType.
def setUp(){
java.util.LinkedHashMap.metaClass.asType = { Class c ->
new grails.converters."$c"(delegate)
}
}
Rember to clean up after yourself in the tearDown, you wouldn't want metaprogramming leaks in your test suite.
def tearDown(){
java.util.LinkedHashMap.metaClass.asType = null
}
Edit:
If you come from the future, consider this answer: https://stackoverflow.com/a/15485593/194932
As Grails 3.3.x grails-test-mixins plugin is deprecated. #see migration guide.
For this problem you should implement GrailsWebUnitTest which is coming from Grails Testing Support Framework.
you can initialise the JSON in the setUp() . There are various marshallers which implement ObjectMarshaller , which need to be added to the ConverterConfiguration for JSON conversion to work.
http://grails.github.io/grails-doc/2.4.4/api/index.html?org/codehaus/groovy/grails/web/converters/marshaller/json/package-summary.html
example :
DefaultConverterConfiguration<JSON> defaultConverterConfig = new DefaultConverterConfiguration<JSON>()
defaultConverterConfig.registerObjectMarshaller(new CollectionMarshaller())
defaultConverterConfig.registerObjectMarshaller(new MapMarshaller())
defaultConverterConfig.registerObjectMarshaller(new GenericJavaBeanMarshaller())
ConvertersConfigurationHolder.setTheadLocalConverterConfiguration(JSON.class, defaultConverterConfig);
I just ran into this, and I really didn't want to implement GrailsWebUnitTest as recommended in another answer here. I want to keep my service test as "pure" and lean as possible. I ended up doing this:
void setupSpec() {
defineBeans(new ConvertersGrailsPlugin())
}
void cleanupSpec() {
ConvertersConfigurationHolder.clear()
}
This is how it happens under the hood when you implement GrailsWebUnitTest (via WebSetupSpecInterceptor and WebCleanupSpecInterceptor).
That said, the converters seem to be meant for use in the web tier, primarily for making it easy to transparently return data in different formats from a controller. It's worth considering why the service you're testing needs the converters in the first place.
For example, in my case, someone used the JSON converter to serialize some data to a string so it could be stored in a single field in the database. That doesn't seem like an appropriate user of the converters, so I plan on changing how it's done. Making the converters available in my service test is a temporary solution to allow me to improve our test coverage before I refactor things.
I was getting the same error when trying to unit test a controller that calls "render myMap as JSON". We use Grails 1.3.7 and none of the other solutions worked for me without introducing other problems. Upgrading Grails was not an alternative for us at the moment.
My solution was to use JSONBuilder instead of "as JSON", like this:
render(contentType: "application/json", {myMap})
See http://docs.grails.org/latest/guide/theWebLayer.html#moreOnJSONBuilder
(I realize this is old, but came here in search for a solution and so might others)