Is it possible to use something other than reflection and the [Fact] attribute on a test method to expose tests to xUnit test runner? For example, I'd like to do something like:
[FactSource] // just making this up
public IEnumerable<ITest> GetUnitTests()
{
yield return new TestCase("test case 1", () => FooAssertion());
yield return new TestCase("test case 2", () => BarAssertion());
}
I've wanted to do this many times to reduce the boilerplate of a function to wrap every single case. Usually it makes sense, but when I am testing 100 API endpoints it's the difference between a file with 100 lines vs. 400 lines of code. Also, I have cases where I want to load the tests from a .JSON or .XML file so it would be great if there was another way to load the tests rather than just [Fact] or [Theory] attributes.
NOTE: [Theory] works great for some tests like this, but it doesn't work for loading the cases from a file or for the case I demonstrate above where I am using lambda expressions.
Thank you!
Check out Exude. It does exactly what you want.
Related
The Cypress documentation suggests that commands are the right way to reuse fragments of code, e.g.
Cypress.Commands.add("logout", () => {
cy.get("[data-cy=profile-picture]").click();
cy.contains("Logout").click();
});
cy.logout();
For simple cases like this, why would I use a command over a plain JS function (and all the nice IDE assistance that comes with it). What are the drawbacks of rewriting the above snippet as
export function logout(){
cy.get("[data-cy=profile-picture]").click();
cy.contains("Logout").click();
}
// and now somewhere in a test
logout();
Based on my experience with Cypress (one year project and several hundred test cases), I can say that a plan JS function is great for grouping cy commands.
From my point of view, a custom cy command may be really useful only if it is incorporated into the chain processing (utilizes the subject parameter or returns a Chainable to be used further in the chain). Otherwise, a plain JS function is preferable due to it simplicity and full IDE support (unless you're using an additional plugin).
If you for any reason need to do something inside the cypress loop, you can always wrap you code by cy.then() in a plain JS function:
function myFunction() {
cy.then(() => {
console.log(("I'm inside the Cypress event loop"))
})
}
Commands are for behavior that is needed across all tests. For example, cy.setup or cy.login. Otherwise, use functions.
See official docs: https://docs.cypress.io/api/cypress-api/custom-commands#1-Don-t-make-everything-a-custom-command
So, I have a beforeEach to load up my site. I am mainly writing my test in one describe function with one it function.
my beforeEach is in the index.js>Support>Cypress folder
beforeEach(() => {
cy.visit('http://localhost:3000/');
});
Current Code Example:
describe('this is a test',function(){
it('will be a test example',function(){
cy.contains('test').click
cy.contains('another test').click()
})
})
A co worker pointed out that I should try to break them up to be more clear on what each test is doing so long as each part can run independently. I have several tests that can run independent, however, the beforeEach kicks in for each it('test_name',function() I write.
For example: I write a test to open a card, click on a state, add data about that state, then close. If I break each part into it's own it then it will have the beforeEach start back on the "home" page of my site.
Example of desired code:
describe('this is a test',function(){
it('will be a test example',function(){
cy.contains('test').click
})
it('will test another test',function(){
cy.contains('another test').click()
})
})
Is there a way for those several it functions to continue on the previous test rather than having the beforeEach effect it?
Thank you in advance.
You can use beforeEach() and before(). The behaviour of both is slightly different.
before() only applies once per describe()
beforeEach()applies for every it() in the describe()
Thus what you have to do:
Put all steps you want to only perform once per describe()in a before(). If there are still steps left which you want to perform every it(), put those in a beforeEach().
Note that you can use both before() and beforeEach() together.
I've splitted my project from one huge test to a few smaller to speed up tests and avoid some errors. Is there any way to run all of them parallel with single conf file? I must pass through login.js before every testcase
specs: ['login.js', 'test1.js'],
I suggest changing your login.js spec into a file which exports a login function. Then create a beforeAll in your onPrepare in your conf. This will be executed before every describe block, which in your case is every test.
onPrepare: function {
beforeAll(function(){
loginToApp();
});
};
I know you have already split up the files but I would seriously consider using the page object model to structure your tests if you have the time.
For an application we use configuration files in which a large number of endpoint characteristics are determined (relations, fillables, visibles, roles, etc.) We would like to loop through these files and conduct automatic tests with PHPUnit, simply to see if we receive a response, if validation errors are being triggered, if the response is in line with the files, etc.
We load the configuration and perform the tests for each endpoint configuration:
public function testConfigurationFiles()
{
$config = resolve('App\Contracts\ConfigInterface');
foreach ($config->resources as $resource=>$configuration) {
foreach ($configuration->endpoints() as $method=>$rules) {
$this->endpoint($method, $resource, $configuration);
}
}
}
After which we use a switch, to test each type of method differently (index, show, create, update, delete). In total this comes down to dozens of tests with hundreds of assertions.
However, if even one of these endpoints fails, the entire tests fails without showing explicit information what went wrong. Is there a way to automatically generate a "test{$resource}{$method}" method for each endpoint, so they will be handled like individual tests?
Besides these tests we also conduct units tests & e2e tests, so we are fully aware of the disadvantages of this way of testing.
After studying PHPUnit some more, I found my answer in dataProviders:
https://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.data-providers
This way you can indicate a data provider for a method, which should return an array with all cases you want to iterate over.
I have a doubt about how to test a simple CSV importer without using the its(:...) clause.
In RSpec 2.x, my approach was to set the imported object as the subject of my spec, and then test each attribute in a its(...) block. It was an acceptance-like test, but it served me well, and I didn't want to unit test the library I used to do my CSV parsing, as it was really a trivial implementation, so I was ok with an end-to-end test.
Now, with RSpec 3, I can make this spec pass with transpec, but I read the explanation about why the its block has been removed and I think RSpec 3 is suggesting a different approach, right? So how would you test that?
I don't think a lot of ugly blocks like this
describe '#email' do
subject { super().email }
it { is_expected.to eq("john_doe#email.com") }
end
are any better than
its(:email) { should == "john.doe#email.com" }
as they do exactly the same thing.
I've read that you need to test "behaviour", but how about acceptance tests? What's the suggested way to go here?
Thanks!
From what I understand, Myron suggests using rspec-given for a one-liner rich test suite. Using this package, your tests will look something like this:
Given(:email) { subject.email }
context "sign up" do
When { subject.sign_up(email: "john.doe#email.com") }
Then { email == "john.doe#email.com" }
end
While the its functionality has been removed from rspec-core, it has been put into an includable gem, rspec-its.
https://github.com/rspec/rspec-its
I would just include this gem and keep writing tests the way you have been - I find them the most readable.
ps. Unrelated but I would also always use eq instead of == in specs :)