I don't know how to make unit test of my rest controller. Here is my code :
public function testpostAction(){
$this->dispatch('/chain');
$this->request->setHeader('Content-Type', 'text/json')
->setMethod('POST')
->setPost(array(
'chain_name' => 'mychaintest'
));
$this->assertAction('post'); ???
}
How I make a post?
Not sure if this is what you need but, if you want to make a POST call (http) to test your REST service, you can use Zend_Http_Client:
http://framework.zend.com/manual/en/zend.http.client.html
Anyway, if this is for unit testing it will be more complicated, since you'll need your application (the current build being testet) to be live and accesible in the server. That depends on how you have configured your build environment.
There should be a staging (virtual) machine where the build is (automatically) deployed before tests are run. That machine should be visible to the machine runing the tests.
Hope this helped. Cheers!
So, basically your question is how to emulate calling PUT and DELETE in your controller tests?
Since this apparently doesn't work:
$this->request->setMethod('PUT');
You can access both these actions with plain HTTP POST by providing _method parameter.
So to call PUT:
$this->request->setMethod('POST');
$this->dispatch('articles/123?_method=put');
To call DELETE:
$this->request->setMethod('POST');
$this->dispatch('articles/123?_method=delete');
More reading on how to deal with RESTful routing here - http://framework.zend.com/manual/en/zend.controller.router.html#zend.controller.router.routes.rest
Related
I have a page with a text field and button. After I fill out text field and press a button my controller is connecting to an API and getting some data based on the text.
I prepared a FAKE_API for testing. Both REAL_API and FAKE_API are in the service container. The FAKE_API is being prioritized when the environment is set to test (.env.test file). The controller gets the API object via dependency injection (constructor argument).
When I am testing using PhpBrowser from Codeception, the environment of the test itself is set to test - this can be checked by var_dump($_ENV['APP_ENV']) from the test.
However, (and this is the issue), if I add var_dump($_ENV['APP_ENV']) to the controller code and run the same test, I can see that the controller actually uses the regular 'dev' environment (set in .env file). This means that the REAL API is being used instead of my FAKE_API.
How can I force PhpBrowser tests to use my .env.test? Is it even possible?
You can't do that.
PhpBrowser communicates to system under test via HTTP, so it can't set environment variables of the system.
Your options are:
Deploy API in test configuration
Pass environment using GET or POST parameters or headers and make your app code accept it. (this is a bad idea)
I would like to test certain conditions on Startup of my ASP.Net Core 2.0 application. For example if my database server or other is running correctly. This is especially helpful for things that will only be instantiated after a request (like my repository).
Currently I have to do this request manually, but I would like to have my application fail early. At what moment and in what place is such a test recommended?
The Startup class is responsible for setting up your server, making it the perfect candidate for setting up one-time initialization stuff for your application.
You usually have two main methods in Startup: ConfigureServices and Configure. The former runs very early and is responsible for setting up the application services, dependencies and configuration. So you cannot use it to actually perform real work, especially since the dependency injection container is not ready yet.
However, the Configure method is different: While its main purpose is to set up the application middleware pipeline, the components that will later serve requests, you are able to fully use your dependencies here, making it possible to already do more extensive things here. So you could make your calls directly here.
It’s important to understand that Configure still runs rather early, way before your server is actually ready to serve requests. So if your initialization depends on the actual server being around already, you should probably further delay the execution.
The proper solution is likely to hook into the application lifecycle using IApplicationLifetime. This type basically offers you a way to register callbacks that are executed during the application lifecycle. In your case, you would be interested in the ApplicationStarted event which runs when the server just completed its setup phase and is now ready to serve requests. So basically the perfect idle moment to run some additional initialization.
In order to respond to a lifetime event, you need to register your handler inside the Configure method:
public void Configure(IApplicationBuilder app, IApplicationLifetime applicationLifetime)
{
// other…
// register lifetime event
applicationLifetime.ApplicationStarted.Register(InitializeApplication);
}
public void InitializeApplication()
{
// do stuff
}
One final note: Apparently, there is currently an open bug that prevents lifetime events from firing when hosting on IIS. In that case, executing your code directly in Configure is probably the best alternative.
I am wondering how I can test an application that's written with fasthttp using the httptest package in the base library of Go.
I found this guide which explains the testing pretty well, but the issue is that httptest does not satisfy the http.Handler interface so I have no idea how to do the http.HandlerFunc since fasthttp uses it's own fasthttp.ListenAndServe that's incompatible.
Any ideas on how to create a wrapper, or how to otherwise test a fasthttp written library end to end?
There are two possible approaches. Unit testing a handler isn't really viable as you would need to create a RequestCtx and stub/mock all necessary fields.
Instead, I would unit test the code that your fasthttp handlers call out
to. I would do e2e testing of the actual handlers themselves.
There is an in memory listener implementation that you could use to avoid actually listening on a TCP port or Unix socket. You would initialise the server but serve on this listener instead of on a network connection.
You would then create a HTTP client and call the relevant methods as normal but use this listener as the transport.
If you stub/fake anything that your handlers interact with then you could make this in-memory only with no external dependencies, i.e. like a unit test but it will actually doing a full system test.
I'm playing with chimp testing tool. At the moment I can easily run cucumber and mocha tests. The problem is that I don't know how to add DB fixtures. I'd like to have initial data before running some tests (e.g. add test user into system).
BTW that data can be added only by authenticated user and users can be create only by admin or from server level.
Can't find any docs about this for now. Any suggestions?
If you are using Meteor, you can pass the DDP parameter on the command line --DDP=http://localhost:3000 and then use server.execute to run code on the server. This code can then setup data.
If you are not using Meteor, you can use a HTTP call using request.get('http://localhost:8080/addUser').
Through HTTP / DDP you can access the server and create a testing backdoor to setup the data you need.
I have a project set up based around the Polymer Starter Kit, which includes Web-Component-Tester
This project includes php server code which I would also like to test by writing tests to run in the browser which will utilise the PHP server code through Ajax Calls.
This implies replacing the server that Web Component Tester is using ONLY when testing server side code. I hope to make a separate gulp task for this.
Unfortunately, I don't understand the relationship between WCT, Selenium and what ever server is run currently. I can see that WCT command starts Selenium, but I can't find out what the web server is and how that is started. I suspect it is WCT, because there is configuration of the mapping of directories to urls, but other than that I haven't a clue, despite trying to read the code.
Can someone explain how I go about making it run its own server when testing the client, but relying on an already set up web server (nginx) when running the server. I can set nginx to run from local host, or an other domain if that is a way to choose a different configuration.
EDIT: I have now found that runner/webserver.js starts an express server, and that urls get mapped so the base directory for the test runner and the bower_components directory both get mapped to the /components url.
What is currently confusing me is in what circumstances this gets run. It appears that loading plugins somehow does it, but my understanding from reading the code for this is tenuous.
The answer is that web component tester itself has a comment in the runner/config.js file.
In wct-conf.js, you can use registerHooks key into the Object that gets returned to add a function that does
registerHooks: function(wct) {
wct.hook('prepare:webserver', function(app, done) {
var proxy = require('express-http-proxy');
app.use('/api',
proxy('pas.dev', {
forwardPath: function(req, res) {
return require('url').parse(req.url).path;
}
})
);
done();
});
This register hook function allows you to provide a route (/api in my case) which this proxies to a server which can run the php scripts.