PHP Laravel framework provides assertion methods like ->assertTrue(), ->assertFalse() for unit testing. However, I cannot find a full list of them. Are they documented somewhere? If not, where can I find them in Laravel source?
Sure. Your test cases all should extend Illuminate\Foundation\Testing\TestCase. This class uses the Illuminate\Foundation\Testing\AssertTrait. Those are all the Laravel specific assertions.
View on github
However assertTrue and assertFalse are both part of PHPUnit itself. You can find a list of all PHPUnit assertions on the official website
Laravel uses PHPUnit and here is the list of phpunit assertions list:
https://gist.github.com/briankip/35e3506be8b1ecbcf3bb
Related
I can't find a lot of info on this but basically I would like to replicate this on a github workflow. In other words:
How can you write tests for custom actions you have developed in a GH workflow ?
if you use:
python => pytest
YAML => checks ?
nodejs => some of the marketplace actions do have tests on them already
bash => ???
I usually dont test my pipeline as code stuff, but somebody brought up the good old argument jenkins is better than GH because of testing, whatever that means
I think this is the closest I can get. if I'll have to validate inputs I could use The GitHub ToolKit for developing GitHub Actions, where I can achieve unit testing in typescript. Couldn't find anything related to python that is actually not supported by github. However, I really don't think it matters since typescript will achieve what I want. I'm open to other ideas if this is wrong
some useful links:
Create your own github action
JS and PR checks
UPDATE:
Looks like my initial response wasn't that far from the truth. Here's a good explanation on all types of testing for github actions
Testing JS GH actions
Using Typescript
We are going with XUnit to run Selenium Functional Tests. In Microsoft Azure Devops, we have a pipeline stage which runs our functional tests.
If the test fails, I want to take a screenshot using the Web Driver and attach it to the test results output.
I know it can be done with NUnit (using TestContext), but how can I achieve this using XUnit? Not sure if this is correct, but is there a way using REST APIs that I could somehow achieve this?
XUnit still doesn't support TestContext, check here: https://github.com/xunit/xunit/issues/2133
After taking the screenshots, you may consider using Attachments - Create Test Result Attachment API to attach the screenshot to a test result:
POST https://dev.azure.com/{organization}/{project}/_apis/test/Runs/{runId}/Results/{testCaseResultId}/attachments?api-version=6.0-preview.1
Looks like xUnit will support it in version 3.0. Currently the teams I work on use the API listed by Cece to push screenshots per-test.
https://github.com/xunit/xunit/issues/621
My team is currently starting to develop a web application with vue.js. We are currently discussing the test framework and a team member prefers cypress. The only issue is, that cypress is not cross platform testing framework. We have requirements to support Chrome, Safari, Edge, tablet and mobile devices.
Most of the modern frameworks such as vuejs promise cross platform functionality. And the raised discussion that we had in the team is the need of cross platform testing. Is it still so important in 2018(almost 2019) to do cross browser and cross OS Platform tests? What do you use for testing and how do you test your web application?
Thank you in advance for your answers.
Of cource the alternative is Selenium using selenium wrappers like Protractor or Webdriver.io or Nightwatch.js.
For same reason, we are not using Cypress. We are using Nightwatch.js. Coz in the above list of wrappers it only has everything inbuilt like cypress. For others in the list we have to find the respective npm for test runner, assertion reporting, parallelisation, etc.
Mainly we have choosed it for internal test runner and junit xml reporting for ci which it gives along with selenium wrapping functionality.
Also one more good thing cypress is working on cross browser support. Recently they have progress in firefox browser.
Refer this issue tracker
We have this same dilemma at my organization. I find Cypress so easy to use that I am ok using it for 99% of my test (that does not include my unit or api test). If I need something special for another browser, which is probably going to be minimal, I would then use a selenium wrapper, for me that would be protractor since we mainly do Angular. I hear a lot of argument not to choose cypress due to the issue that it currently only runs in Chrome, I think sometimes it is an excuse for someone to hate it because they don't want to learn something new. I would bet 90% or more of your test cases Cypress will be just fine, where I need something else I do something else. When I look at the testing triangle, I know most of my test should be UNIT test so I don't have enough UI automation test to worry about it. I will say I have ran into this same argument at my job from developers who say why don't use protractor, and they have the freedom to use protractor, but I notice they never get around to using it. They like to argue about what someone else wants to do, but then they don't even use what they say they prefer. I would ask myself what is going to be the cheapest to implement and be the most effective for me. For me that is mainly cypress and then protractor if I have some special case..
Currently, with my Intern setup, I'm using an unbuilt Dojo build when running my Intern tests; like, for example, a test module loads app/ProductModuleA, and ProductModuleA references and loads dojo/request. I need to have the dojo/request.js file in the appropriate directory structure in order for the module to be resolved without errors and therefore the test to be able to run. Our product code does use a built dojo.js file and our previous DOH tests were able to use this, too, without any issues--I don't understand how that worked because I don't know anything really about building Dojo.
I know I've seen snippets in various Internet forums (like here) and the Intern User Guide that Intern supports source maps, which I guess suggests it's possible to use a built dojo.js file in conjunction with running Intern, but I haven't found anything at all in detail. Insights, or pointers to documentation or examples that so far I haven't been able to find?
One of the benefits of AMD is that you don't have to do anything special to your code when switching between a built and unbuilt Dojo. The first time you load a dependency using an unbuilt Dojo, the loader requests it over the network and then caches the result. Subsequent loads use the cached dependency. The loading process works the same with a built Dojo; the main difference is that all the modules built into the built Dojo are pre-cached. The loader doesn't have to request them over the network the first time because they start out in the module cache.
For Intern to use a built Dojo, you just need to make sure you're using the built Dojo as your loader during tests. You can do this by setting the useLoader option in your Intern config.
I tried what Jason suggested and it still didn't work--I was getting 404s for a Dojo_ROOT.js module, though nothing in tests or product files explicitly load that. I'm sure this is due to something unique in my product's build environment. That's okay, I will just use the Dojo source for now and return to this later.
I'm writing an API using a non-rails framework. I normally use Cucumber for BDD and testing of API's when I'm writing them in RAILS.
Is there a strong reason not to use Cucumber when I'm testing an API written on top of node.js (or any other framework, really)?
Strong technical reasons to not do this might include:
Dependency of Cucumber on Rails
The existence of a better framework for node.js
Some other technical reason I don't know about.
First of all, Cucumber doesn't depend on Rails.
I have been trying out some different javascript testing frameworks to try to work out what I want to use. So far I like mocha with expect.js for unit testing but I haven't found anything for integration testing a node app that I'm happy with. It's possible to do with mocha and supertest, and I've also tried cucumber.js which is getting there but it's not as mature as the Ruby version - so that's what I intend to use.
I can't think of a good reason not to do this, apart from it may be harder to do things like set up fixtures - but that may well be a good thing as it would force your tests to deal only with the public interface of your API - as it was intended to be used.
As said cucumber has nothing to do with rails.
You could perfectly use it to test API's written in any languages.
In case you want to use node.js full stack cucumber.js is a good option.