In Grails the unit tests and integration tests get generated with exactly the same naming convention, so that if you are testing a domain class named Foo both tests get generated with the name FooTests, in the same package. Is there an expectation I should have either a unit test or an integration test, but not both? Do people put their integration tests in a different package from their unit tests, or rename one? What's the preferred way to get around this?
btw I hacked on grails/scripts/_GrailsCreateArtifacts.groovy to change how the classes are generated in order to get it to generate different names (the value for the suffix property is all that changed). I don't like having to include something that means 'integration' in the name when the class is in a folder called 'integration', but this at least avoids having to do a manual rename.
createIntegrationTest = { Map args = [:] ->
def superClass = args["superClass"] ?: "GroovyTestCase"
createArtifact(name: args["name"], suffix: "${args['suffix']}IntTests",
type: "Tests", path: "test/integration", superClass: superClass)
}
I think giving them a different name is the right choice.
*IntTests
or
*IntegrationTests
Related
I have a __mocks__ folder that mocks out a node module. This works for most of my tests, but in one particular test I need a custom mock. I need my unit-tested code to ignore the mock in the __mocks__ folder, and use a specific mock that I define in the test file.
I tried using jest.unmock(), however this prevents me from defining specific mocks in my unit test (thing.test.js). If I then add some mocks or modify the module I'm mocking, the changes don't get added to the code I'm testing (thing.js).
Example:
thing.js imports AWS.js module
__mocks__/AWS.js contains AWS.js module mock
other tests use __mocks__/AWS.js
thing.test.js wants to create a custom mock that doesn't get overwritten by __mocks__/AWS.js and doesn't affect other tests -> how to do this??
I am using Typescript, but the same approach applies. I create my normal test files (thing.spec.ts) which tests the code. In our code base, we do basic tests in this file, and would use it to test non-mocked functions, and simply spyOn() calls.
We then create a separate test file (thing.mock.spec.ts) where the 'mock' indicates that the tests in the this file, are going to be using the __mock__ directory class instead. The naming is just our internal standard to be clear of what we are using.
In the thing.mock.spec.ts we do the mock of the complete class as you are doing in your test. This test file only tests functions that require the mock data, since the main tests have been done independently in the thing.spec.ts.
This would then have:
__mocks__/AWS.js
thing.js
thing.test.js
thing.mock.test.js
This way, when looking at just the file names, you get a sense of what is being used during the testing.
I have a big set of unit and some integration tests implemented with google test framework or gtest.
Since there is no tagging I am using the disable convention to separate tests in groups or prefixing them with GROUPA_, GROUPB_, etc.
This works well. I can filter different groups, to run in different situations etc.
The problem I have is with typed tests that belong to different groups. Since the name of the test is fixed no matter what arguments I pass to the test fixture I cannot assign the same test to more than one group.
My question is, can I control the name of the test somehow runtime before the runner or something. Any other way to control the name of a typed tests?
As a workaround, you can include a typed test into the different groups but for all the types. You could use as many prefixes as needed:
TYPED_TEST(FooTest, GROUPA_GROUPB_Bar)
{
}
Then use filtering strings like FooTest.*GROUPX*_Bar.
I cannot think of a way to map each type the test is instanciated for to a a different group.
I can add a method to the java Integer type in Groovy with the lines:
ExpandoMetaClass.EnableGlobally()
Integer.metaClass.gimmeAP = {->return 'p'}
I don't know why I'd need that, but it gets the point across. Now I can make calls to Integers and get back a 'p'. Now lets say I want this in a grails app so I can make calls in the domain objects. The specific problem I'm having is that when I put those metaprogramming lines in the bootstrap all the metaprogramming isn't available in the unit tests, so my unit tests are failing with errors like "No method gimmeAP for java.lang.Integer" or something like that.
How do I either include the metaprogramming better, or execute that part of the bootstrap so I can use my tricked out syntax in unit tests?
I have seen this question: Grails - Making Methods Globally Available and Metaclass Programming and it seems my line ExpandoMetaClass.EnableGlobally() may fix his problem, but am I using it right?
Bootstrap isn't executed for unit tests. I would personally prefer to create a mockFoo method that does the above meta programming, and Then I will call the mockFoo from the test setup.
Also look at the GrailsUnitTestCase.registerMetaClass. Register metaclass before you add mock methods, so that they don't leak in other tests.
registerMetaClass(SecurityUtils)
SecurityUtils.metaClass.'static'.getSubject = { ->
return [logout: { return true } ] as Subject
}
I know you want to make your dynamic methods available to all unit tests, but there's nothing such as bootstrap for unit tests. So you have to do it in each test.
You can create a MockHelper with a static method, and call it from test setUp.
This is probably a really easy one, but I can't seem to find the answer.
I have written some custom assert functions for unit testing my models. I would like these functions to be available in all of my unit tests, no matter the model. Where would I put these so that they are available to every unit test?
I use MyCakeTestCase which extends the CakeTestCase.
There I can put all my custom methods.
see this test for example:
https://github.com/dereuromark/tools/blob/2.0/Test/Case/Lib/CaptchaLibTest.php
just put your own test case in your lib folder (either app or - as I prefer - plugin):
/app/Lib/
/app/Plugin/PluginName/Lib/
and either lib or pluginlib uses statement:
App::uses('MyCakeTestCase', 'Lib');
App::uses('MyCakeTestCase', 'PluginName.Lib');
I'm somewhat new to writing tests. I've find myself struggling with keeping my setUp's clean and concise, instead trying to accomplish too much with an uber-setUp.
My question is, how do you split up your testing?
Do your tests include one or two lines of independent step code?
def test_public_items():
item1 = PublicItem()
item2 = PublicItem()
assertEqual(public_items, [item1, item2])
or do you factor that into the setUp no matter what?
If that's the case, how do you deal with test class separation? Do you create a new class when one set of tests needs a different setUp then another set of tests?
I believe you've hit a couple of anti-patterns here
Excessive Setup
Inappropriately shared fixture.
The rule of thumb is that all tests in a particular test fixture should need the code in the Setup() method.
If you write a test() that needs more or less setup that what is currently present, it may be a hint that it belongs to a new test fixture. Inertia to create a new test fixture.. is what snowballs the setup code into one big ball of mud - trying to do everything for all tests. Hurts readability quite a bit.. you can't see the test amid the setup code, most of which may not even be relevant for the test you're looking at.
That said it is okay to have a test have some specific setup instructions right in the test over the common setup. (That belongs to the first of the Arrange-Act-Assert triad). However if you have duplication of those instructions in multiple tests - you should probably take all those tests out to a new test fixture, whose
setup_of_new_fixture = old_setup + recurring_arrange_instruction
Yes, a text fixture (embodied in a class) should exactly be a set of tests sharing common needs for set-up and tear-down.
Ideally, a unit test should be named testThisConditionHolds. public_items is not a "condition". Wherever the incredibly-black-magic public_items is supposed to come from I'd be writing tests like:
def testNoPublicItemsRecordedIfNoneDefined(self):
assertEqual([], public_items)
def testOnePublicItemsIsRecordedRight(self):
item = PublicItem()
assertEqual([item], public_items)
def testTwoPublicItemsAreRecordedRight(self):
item1 = PublicItem()
item2 = PublicItem()
assertEqual([item1, item2], public_items)
If public_items is a magical list supposed to be magically populated as a side effect of calling a magic function PublicItem, then calling the latter in setUp would in fact destroy the ability to test these simple cases properly, so of course I wouldn't do it!