I've written some code in Vue that is working correctly but the unit tests are throwing warnings.
I'm using the library d3 and for setting the datum this function
.datum(function() {
return (this.nextSibling as SVGGraphicsElement).getBBox();
})
This is working, the unit tests with Mocha are also passing but I'm getting this warning
TypeError: this.nextSibling.getBBox is not a function
Any idea about what might be wrong and how to avoid that warning on the tests?
Related
I want to migrate jest unit tests from vue 2 to vue 3. But I'm stuck with mocking up computed props.
I got a lot of vue-2 unit tests written like this:
const wrapper = shallowMount(FooComponent, {
computed: {
myComputedProp: () => false // The intention is to return "false" during unit tests no matter what
}
});
That was working in vue 2 world, but seems has no effect after the migration to vue 3 and the compatible vue-test utils.
Some of the components atm on composition api, while the others yet on options api.
I'd prefer to not re-write all these unit tests, cause it's a migration, but find a way to mock computed props once again if that's possible.
Thanks
I'm writing a new Vue project and want to test my components with vue-test-utils.
So far I've been writing unit-tests with a test case for each component method, testing its expected behavior while mocking other methods that it might call.
Recently I've read on the Vue docs that the unit tests for components should test general behavior and not rely on implemenation details:
https://vuejs.org/guide/scaling-up/testing.html#component-testing
which makes sense, but I still want to test the logic of my component's methods.
I don't want to extract it to different files / composables because they heavily rely on the component's data and other methods, and I don't wanna pass everything as parameters.
What do you recommend regarding this?
I can't mock methods anymore since setMethods is now deprecated in vue-test-utils, which is making it harder to test each method separately.
do you think I should give up on testing each method?
I find it helpful to test methods because usually small changes make those tests fail which help me notice errors in the code, but also makes it harder because every small legitimate change requires unit-test changes as well.
We have done unit test using vue-jest. Here are the steps.
Use the following code to set up the crypto property globally. This will allow Jest to access window.crypto and won't cause any issue.Create a crypto.mock file and paste following code.
const crypto = require('crypto')
Object.defineProperty(global.self, 'crypto', {
value: {
getRandomValues: arr => crypto.randomBytes(arr.length)
}
})
Now import this file in your test file component. Now You can use jasmine.Spy to spy on the elements.
let spyFor: jasmine.Spy; spyFor = spyOn(function.hello, 'hello'); expect(spyFor).toHaveBeenCalledTimes(1);
In this way you can mock on the methods. Pls free to ask if you have anything more.
I'm running androidTest UI tests against the proguarded release build of my project, so that we can catch proguard misconfiguartions in an early phase of development. However this causes issues when we use production methods in UI tests that are not used (1) in production code. Because proguard only traverse the implementation tree of dependencies and not androidTestImplementation, those methods will be dropped or altered. See illustration.
Is there anyway I can instruct proguard to also traverse the androidTestImplementation dependecy tree before minifying production code?
In this illustration method m1() will be dropped from the relase build APK since "App main" is not calling it. The UI tests will fail because the method is not found.
(1) Not used or used differently: For instance if a method has a boolean input parameter and all invocations in production code send in "true", proguard will hard code that value to true and drop the parameter from the signature. If a UI test calls the method with "false" it will then not find the method signature. Now you can argue that since all production invocations are with value "true" the method should be changed anyway and you are right - but I think the punishment of failing the tests is too harsh. It should be a compiler or lint warning, not a UI test fail with NoSuchMethodError.
I'm trying to figure out how to best organize my tests in Rust, and I'm running into the following problem. I have a test utility (test_util) that I define in a module and I would like to be able to use it from my unit tests as well as from my integration tests.
Definition of test_util in src/lib.rs:
#[cfg(test)]
pub mod test_util {
pub fn test_helper() {}
}
I can access my helper function from my unit tests in another module, src/some_module.rs:
#[cfg(test)]
pub mod test {
use crate::test_util::test_helper;
#[test]
fn test_test_helper() {
test_helper();
}
}
However, when I try to use the utility from my integration test, as in tests/integration_test.rs:
use my_project::test_util::test_helper;
#[test]
fn integration_test_test_helper() {
test_helper();
}
I get the following compiler message:
8 | use my_project::test_util::test_helper;
| ^^^^^^^^^ could not find `test_util` in `my_project`
Is there a good reason why it is not allowed to access test code from the project from within an integration test belonging to that same project? I get it that integration tests can only access the public parts of the code, but I think it would make sense to also allow access to the public parts of the unit test code. What would be a work around for this?
The test feature is only enabled while tests are being run on that crate. Integration tests are run externally to the crate, so you cannot access anything that is gated on test.
In my company we have a convention to put shared test utilities in a public test_utils module at the top level of a crate. You could gate this module behind your own feature, say integration_test, which you always enable when running those tests, but we don't currently bother with that.
I have a bit of a special situation. Basically I have a unit test, annotated with #Test, and inside that test I need to execute a Cucumber JVM test class.
Why? Long story. Something to do with classloaders and RoboGuice, it's not very important but it does impose limits on what I can and cannot do.
Here's the test method:
#Test
public void runCucumberFeature() throws Exception {
Cucumber cucumber = new Cucumber(MyCucumberTest.class);
cucumber.run(new RunNotifier());
}
MyCucumberTest is a class I have created, and annotated like this:
//#RunWith(Cucumber.class)
#Cucumber.Options(format = {"pretty", "html:target/cucumber"}, strict=true)
public class MyCucumberTest {
// Empty, as required by Cucumber JVM
}
Why have I commented out the #RunWith annotation? Because if I don't, the Cucumber test runner will pick up the test and run it, which I don't want because I am running the test manually.
The problem is that the above doesn't work. It looks like Cucumber is finding the feature files, it is verifying that MyCucumberTest contains the #Givens etc, it even prints out the test as if it was running it.
But it doesn't. No code is executing inside the #Given, #When and #Then methods. I'm not sure why this is, but I have a vague idea that the Cucumber JVM test runner doesn't want to execute the code because the class isn't annotated with #RunWith.
Can anyone help?
I can't provide the solution you're looking for, but....
... have you considered tagging the test that you want to run manually (e.g. with #Manual)?
Then you could uncomment your #RunWith annototation and exclude the manual test by adding --tags ~#Manual to your Cucumber-JVM invocation.
In your manual JUnit invocation you could add --tags #Manual