Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Mojolicious::Guides::TUseriContributed Perl DoMojolicious::Guides::Tutorial(3)

       Mojolicious::Guides::Tutorial - Get started with	Mojolicious

       A quick example-driven introduction to the wonders of
       Mojolicious::Lite. Almost everything you'll learn here also applies to
       full Mojolicious	applications.

       This is only the	first of the Mojolicious::Guides. Other	guides delve
       deeper into topics like growing a Mojolicious::Lite prototype into a
       well-structured Mojolicious application,	routing, rendering and more.
       It is highly encouraged that readers continue on	to the remaining
       guides after reading this one.

   Hello World
       A simple	Hello World application	can look like this, strict, warnings,
       utf8 and	Perl 5.16 features are automatically enabled and a few
       functions imported, when	you use	Mojolicious::Lite, turning your	script
       into a full featured web	application.

	 #!/usr/bin/env	perl
	 use Mojolicious::Lite -signatures;

	 get '/' => sub	($c) {
	   $c->render(text => 'Hello World!');


       With Mojolicious::Command::Author::generate::lite_app there is also a
       helper command to generate a small example application.

	 $ mojo	generate lite-app

       Many different commands are automatically available from	the command
       line. CGI and PSGI environments can even	be detected and	will usually
       just work without commands.

	 $ ./ daemon
	 Web application available at

	 $ ./ daemon -l	http://*:8080
	 Web application available at

	 $ ./ cgi
	 ...CGI	output...

	 $ ./ get /
	 Hello World!

	 $ ./
	 ...List of available commands (or automatically detected environment)...

       A call to "start" in Mojolicious	("app->start"),	which starts the
       command system, should be the last expression in	your application,
       because its return value	can be significant.

	 # Use @ARGV to	pick a command

	 # Start the "daemon" command
	 app->start('daemon', '-l', 'http://*:8080');

       Your application	will automatically reload itself if you	start it with
       the morbo development web server, so you	don't have to restart the
       server after every change.

	 $ morbo ./
	 Web application available at

       For more	information about how to deploy	your application see also
       "DEPLOYMENT" in Mojolicious::Guides::Cookbook.

       Routes are basically just fancy paths that can contain different	kinds
       of placeholders and usually lead	to an action, if they match the	path
       part of the request URL.	The first argument passed to all actions ($c)
       is a Mojolicious::Controller object, containing both the	HTTP request
       and response.

	 use Mojolicious::Lite -signatures;

	 # Route leading to an action that renders some	text
	 get '/foo' => sub ($c)	{
	   $c->render(text => 'Hello World!');


       Response	content	is often generated by actions with "render" in
       Mojolicious::Controller,	but more about that later.

   GET/POST parameters
       All "GET" and "POST" parameters sent with the request are accessible
       via "param" in Mojolicious::Controller.

	 use Mojolicious::Lite -signatures;

	 # /foo?user=sri
	 get '/foo' => sub ($c)	{
	   my $user = $c->param('user');
	   $c->render(text => "Hello $user.");


   Stash and templates
       The "stash" in Mojolicious::Controller is used to pass data to
       templates, which	can be inlined in the "DATA" section.  A few stash
       values like "template", "text" and "data" are reserved and will be used
       by "render" in Mojolicious::Controller to decide	how a response should
       be generated.

	 use Mojolicious::Lite -signatures;

	 # Route leading to an action that renders a template
	 get '/foo' => sub ($c)	{
	   $c->stash(one => 23);
	   $c->render(template => 'magic', two => 24);


	 @@ magic.html.ep
	 The magic numbers are <%= $one	%> and <%= $two	%>.

       For more	information about templates see	also "Embedded Perl" in

       "req" in	Mojolicious::Controller	and "res" in Mojolicious::Controller
       give you	full access to all HTTP	features and information.

	 use Mojolicious::Lite -signatures;

	 # Access request information
	 get '/agent' => sub ($c) {
	   my $host = $c->req->url->to_abs->host;
	   my $ua   = $c->req->headers->user_agent;
	   $c->render(text => "Request by $ua reached $host.");

	 # Echo	the request body and send custom header	with response
	 post '/echo' => sub ($c) {
	   $c->res->headers->header('X-Bender' => 'Bite	my shiny metal ass!');
	   $c->render(data => $c->req->body);


       You can test the	more advanced examples right from the command line
       with Mojolicious::Command::get.

	 $ ./ get -v -M	POST -c	'test' /echo

       JSON is the most	commonly used data-interchange format for web
       services. Mojolicious loves JSON	and comes with the possibly fastest
       pure-Perl implementation	Mojo::JSON built right in, which is accessible
       through "json" in Mojo::Message as well as the reserved stash value

	 use Mojolicious::Lite -signatures;

	 # Modify the received JSON document and return	it
	 put '/reverse'	=> sub ($c) {
	   my $hash = $c->req->json;
	   $hash->{message} = reverse $hash->{message};
	   $c->render(json => $hash);


       You can send JSON documents from	the command line with

	 $ ./ get -M PUT -c '{"message":"Hello Mojo!"}'	/reverse

   Built-in "exception"	and "not_found"	pages
       During development you will encounter these pages whenever you make a
       mistake,	they are gorgeous and contain a	lot of valuable	information
       that will aid you in debugging your application.

	 use Mojolicious::Lite -signatures;

	 # Not found (404)
	 get '/missing'	=> sub ($c) {
	   $c->render(template => 'does_not_exist');

	 # Exception (500)
	 get '/dies' =>	sub { die 'Intentional error' };


       You can even use	CSS selectors with Mojolicious::Command::get to
       extract only the	information you're actually interested in.

	 $ ./ get /dies	'#error'

       And don't worry about revealing too much	information on these pages,
       they are	only available during development, and will be replaced
       automatically with pages	that don't reveal any sensitive	information in
       a production environment.

   Route names
       All routes can have a name associated with them,	this allows automatic
       template	detection and backreferencing with "url_for" in
       Mojolicious::Controller,	on which many methods and helpers like
       "link_to" in Mojolicious::Plugin::TagHelpers rely.

	 use Mojolicious::Lite -signatures;

	 # Render the template "index.html.ep"
	 get '/' => sub	($c) {
	 } => 'index';

	 # Render the template "hello.html.ep"
	 get '/hello';


	 @@ index.html.ep
	 <%= link_to Hello  => 'hello' %>.
	 <%= link_to Reload => 'index' %>.

	 @@ hello.html.ep
	 Hello World!

       Nameless	routes get an automatically generated one assigned that	is
       simply equal to the route itself	without	non-word characters.

       Templates can have layouts too, you just	select one with	the helper
       "layout"	in Mojolicious::Plugin::DefaultHelpers and place the result of
       the current template with the helper "content" in

	 use Mojolicious::Lite;

	 get '/with_layout';


	 @@ with_layout.html.ep
	 % title 'Green';
	 % layout 'green';
	 Hello World!

	 @@ layouts/green.html.ep
	 <!DOCTYPE html>
	   <head><title><%= title %></title></head>
	   <body><%= content %></body>

       The stash or helpers like "title" in
       Mojolicious::Plugin::DefaultHelpers can be used to pass additional data
       to the layout.

       Template	blocks can be used like	normal Perl functions and are always
       delimited by the	"begin"	and "end" keywords, they are the foundation
       for many	helpers.

	 use Mojolicious::Lite;

	 get '/with_block' => 'block';


	 @@ block.html.ep
	 % my $link = begin
	   % my	($url, $name) =	@_;
	   Try <%= link_to $url	=> begin %><%= $name %><% end %>.
	 % end
	 <!DOCTYPE html>
	   <head><title>Sebastians frameworks</title></head>
	     %=	$link->('', 'Mojolicious')
	     %=	$link->('',	'Catalyst')

       Helpers are little functions you	can create with	the keyword "helper"
       in Mojolicious::Lite and	reuse throughout your whole application, from
       actions to templates.

	 use Mojolicious::Lite -signatures;

	 # A helper to identify	visitors
	 helper	whois => sub ($c) {
	   my $agent = $c->req->headers->user_agent || 'Anonymous';
	   my $ip    = $c->tx->remote_address;
	   return "$agent ($ip)";

	 # Use helper in action	and template
	 get '/secret' => sub ($c) {
	   my $user = $c->whois;
	   $c->app->log->debug("Request	from $user");


	 @@ secret.html.ep
	 We know who you are <%= whois %>.

       A list of all built-in ones can be found	in
       Mojolicious::Plugin::DefaultHelpers and

       Plugins are application extensions that help with code sharing and
       organization. You can load a plugin with	the keyword "plugin" in
       Mojolicious::Lite, which	can omit the "Mojolicious::Plugin::" part of
       the name, and optionally	provide	configuration for the plugin.

	 use Mojolicious::Lite;

	 plugin	Config => {file	=> '/etc/myapp.conf', default => {foo => 'bar'}};

	 # Return configured foo value,	or default if no configuration file
	 get '/foo' => sub ($c)	{
	   my $foo = $c->app->config('foo');
	   $c->render(json => {foo => $foo});


       Mojolicious::Plugin::Config is a	built-in plugin	which can populate
       "config"	in Mojolicious using a config file.  Plugins can also set up
       routes, hooks, handlers,	or even	load other plugins. A list of built-in
       plugins can be found at "PLUGINS" in Mojolicious::Plugins, and many
       more are	available from CPAN

       Route placeholders allow	capturing parts	of a request path until	a "/"
       or "." separator	occurs,	similar	to the regular expression "([^/.]+)".
       Results are accessible via "stash" in Mojolicious::Controller and
       "param" in Mojolicious::Controller.

	 use Mojolicious::Lite -signatures;

	 # /foo/test
	 # /foo/test123
	 get '/foo/:bar' => sub	($c) {
	   my $bar = $c->stash('bar');
	   $c->render(text => "Our :bar	placeholder matched $bar");

	 # /testsomething/foo
	 # /test123something/foo
	 get '/<:bar>something/foo' => sub ($c)	{
	   my $bar = $c->param('bar');
	   $c->render(text => "Our :bar	placeholder matched $bar");


       To separate them	from the surrounding text, you can surround your
       placeholders with "<" and ">", which also makes the colon prefix

   Relaxed Placeholders
       Relaxed placeholders allow matching of everything until a "/" occurs,
       similar to the regular expression "([^/]+)".

	 use Mojolicious::Lite;

	 # /hello/test
	 # /hello/test.html
	 get '/hello/#you' => 'groovy';


	 @@ groovy.html.ep
	 Your name is <%= $you %>.

   Wildcard placeholders
       Wildcard	placeholders allow matching absolutely everything, including
       "/" and ".", similar to the regular expression "(.+)".

	 use Mojolicious::Lite;

	 # /hello/test
	 # /hello/test123
	 # /hello/test.123/test/123
	 get '/hello/*you' => 'groovy';


	 @@ groovy.html.ep
	 Your name is <%= $you %>.

   HTTP	methods
       Routes can be restricted	to specific request methods with different
       keywords	like "get" in Mojolicious::Lite	and "any" in

	 use Mojolicious::Lite -signatures;

	 # GET /hello
	 get '/hello' => sub ($c) {
	   $c->render(text => 'Hello World!');

	 # PUT /hello
	 put '/hello' => sub ($c) {
	   my $size = length $c->req->body;
	   $c->render(text => "You uploaded $size bytes	to /hello.");

	 any ['GET', 'POST', 'PATCH'] => '/bye'	=> sub ($c) {
	   $c->render(text => 'Bye World!');

	 # * /whatever
	 any '/whatever' => sub	($c) {
	   my $method =	$c->req->method;
	   $c->render(text => "You called /whatever with $method.");


   Optional placeholders
       All placeholders	require	a value, but by	assigning them default values
       you can make capturing optional.

	 use Mojolicious::Lite -signatures;

	 # /hello
	 # /hello/Sara
	 get '/hello/:name' => {name =>	'Sebastian', day => 'Monday'} => sub ($c) {
	   $c->render(template => 'groovy', format => 'txt');


	 @@ groovy.txt.ep
	 My name is <%=	$name %> and it	is <%= $day %>.

       Default values that don't belong	to a placeholder simply	get merged
       into the	stash all the time.

   Restrictive placeholders
       A very easy way to make placeholders more restrictive are alternatives,
       you just	make a list of possible	values.

	 use Mojolicious::Lite -signatures;

	 # /test
	 # /123
	 any '/:foo' =>	[foo =>	['test', '123']] => sub	($c) {
	   my $foo = $c->param('foo');
	   $c->render(text => "Our :foo	placeholder matched $foo");


       All placeholders	get compiled to	a regular expression internally, this
       process can also	be customized. Just make sure not to use "^" and "$",
       or capturing groups "(...)", non-capturing groups "(?:...)" are fine

	 use Mojolicious::Lite -signatures;

	 # /1
	 # /123
	 any '/:bar' =>	[bar =>	qr/\d+/] => sub	($c) {
	   my $bar = $c->param('bar');
	   $c->render(text => "Our :bar	placeholder matched $bar");


       You can take a closer look at all the generated regular expressions
       with the	command	Mojolicious::Command::routes.

	 $ ./ routes -v

       Authentication and code shared between multiple routes can be realized
       easily with routes generated by "under" in Mojolicious::Lite. All
       following routes	are only evaluated if the callback returned a true

	 use Mojolicious::Lite -signatures;

	 # Authenticate	based on name parameter
	 under sub ($c)	{

	   # Authenticated
	   my $name = $c->param('name')	|| '';
	   return 1 if $name eq	'Bender';

	   # Not authenticated
	   $c->render(template => 'denied');
	   return undef;

	 # Only	reached	when authenticated
	 get '/' => 'index';


	 @@ denied.html.ep
	 You are not Bender, permission	denied.

	 @@ index.html.ep
	 Hi Bender.

       Prefixing multiple routes is another good use for it.

	 use Mojolicious::Lite;

	 # /foo
	 under '/foo';

	 # /foo/bar
	 get '/bar' => {text =>	'foo bar'};

	 # /foo/baz
	 get '/baz' => {text =>	'foo baz'};

	 # / (reset)
	 under '/' => {msg => 'whatever'};

	 # /bar
	 get '/bar' => {inline => '<%= $msg %> works'};


       You can also group related routes with "group" in Mojolicious::Lite,
       which allows nesting of routes generated	with "under" in

	 use Mojolicious::Lite -signatures;

	 # Global logic	shared by all routes
	 under sub ($c)	{
	   return 1 if $c->req->headers->header('X-Bender');
	   $c->render(text => "You're not Bender.");
	   return undef;

	 # Admin section
	 group {

	   # Local logic shared	only by	routes in this group
	   under '/admin' => sub ($c) {
	     return 1 if $c->req->headers->header('X-Awesome');
	     $c->render(text =>	"You're	not awesome enough.");
	     return undef;

	   # GET /admin/dashboard
	   get '/dashboard' => {text =>	'Nothing to see	here yet.'};

	 # GET /welcome
	 get '/welcome'	=> {text => 'Hi	Bender.'};


       Formats can be automatically detected from file extensions like
       ".html",	they are used to find the right	template and generate the
       correct "Content-Type" header.

	 use Mojolicious::Lite -signatures;

	 # /detection
	 # /detection.html
	 # /detection.txt
	 get '/detection' => sub ($c) {
	   $c->render(template => 'detected');


	 @@ detected.html.ep
	 <!DOCTYPE html>
	   <body>HTML was detected.</body>

	 @@ detected.txt.ep
	 TXT was detected.

       The default format is "html", and restrictive placeholders can be used
       to limit	possible values.

	 use Mojolicious::Lite -signatures;

	 # /hello.json
	 # /hello.txt
	 get '/hello' => [format => ['json', 'txt']] =>	sub ($c) {
	   return $c->render(json => {hello => 'world'})
	     if	$c->stash('format') eq 'json';
	   $c->render(text => 'hello world');


       Or you can just disable format detection	with a special type of
       restrictive placeholder.

	 use Mojolicious::Lite;

	 # /hello
	 get '/hello' => [format => 0] => {text	=> 'No format detection.'};

	 # Disable detection and allow the following routes to re-enable it on demand
	 under [format => 0];

	 # /foo
	 get '/foo' => {text =>	'No format detection again.'};

	 # /bar.txt
	 get '/bar' => [format => 'txt'] => {text => ' Just one	format.'};


   Content negotiation
       For resources with different representations and	that require truly
       RESTful content negotiation you can also	use "respond_to" in

	 use Mojolicious::Lite -signatures;

	 # /hello (Accept: application/json)
	 # /hello (Accept: application/xml)
	 # /hello.json
	 # /hello.xml
	 # /hello?format=json
	 # /hello?format=xml
	 get '/hello' => sub ($c) {
	     json => {json => {hello =>	'world'}},
	     xml  => {text => '<hello>world</hello>'},
	     any  => {data => '', status => 204}


       MIME type mappings can be extended or changed easily with "types" in

	 app->types->type(rdf => 'application/rdf+xml');

   Static files
       Similar to templates, but with only a single file extension and
       optional	Base64 encoding, static	files can be inlined in	the "DATA"
       section and are served automatically.

	 use Mojolicious::Lite;


	 @@ something.js

	 @@ test.txt (base64)

       External	static files are not limited to	a single file extension	and
       will be served automatically from a "public" directory if it exists.

	 $ mkdir public
	 $ mv something.js public/something.js
	 $ mv mojolicious.tar.gz public/mojolicious.tar.gz

       Both have a higher precedence than routes for "GET" and "HEAD"
       requests. Content negotiation with "Range", "If-None-Match" and
       "If-Modified-Since" headers is supported	as well	and can	be tested very
       easily with Mojolicious::Command::get.

	 $ ./ get /something.js	-v -H 'Range: bytes=2-4'

   External templates
       External	templates will be searched by the renderer in a	"templates"
       directory if it exists.

	 $ mkdir -p templates/foo
	 $ echo	'Hello World!' > templates/foo/bar.html.ep

       They have a higher precedence than templates in the "DATA" section.

	 use Mojolicious::Lite -signatures;

	 # Render template "templates/foo/bar.html.ep"
	 any '/external' => sub	($c) {
	   $c->render(template => 'foo/bar');


       You can use "home" in Mojolicious to interact with the directory	your
       application considers its home. This is the directory it	will search
       for "public" and	"templates" directories, but you can use it to store
       all sorts of application	specific data.

	 $ mkdir cache
	 $ echo	'Hello World!' > cache/hello.txt

       There are many useful methods Mojo::Home	inherits from Mojo::File, like
       "child" in Mojo::File and "slurp" in Mojo::File,	that will help you
       keep your application portable across many different operating systems.

	 use Mojolicious::Lite -signatures;

	 # Load	message	into memory
	 my $hello = app->home->child('cache', 'hello.txt')->slurp;

	 # Display message
	 get '/' => sub	($c) {
	   $c->render(text => $hello);

       You can also introspect your application	from the command line with

	 $ ./ eval -v 'app->home'

       Conditions such as "agent" and "host" from
       Mojolicious::Plugin::HeaderCondition allow even more powerful route

	 use Mojolicious::Lite -signatures;

	 # Firefox
	 get '/foo' => (agent => qr/Firefox/) => sub ($c) {
	   $c->render(text => 'Congratulations,	you are	using a	cool browser.');

	 # Internet Explorer
	 get '/foo' => (agent => qr/Internet Explorer/)	=> sub ($c) {
	   $c->render(text => 'Dude, you really	need to	upgrade	to Firefox.');

	 get '/bar' => (host =>	'') => sub ($c) {
	   $c->render(text => 'Hello Mojolicious.');


       Cookie-based sessions just work out of the box, as soon as you start
       using them through the helper "session" in
       Mojolicious::Plugin::DefaultHelpers. Just be aware that all session
       data gets serialized with Mojo::JSON and	stored client-side, with a
       cryptographic signature to prevent tampering.

	 use Mojolicious::Lite -signatures;

	 # Access session data in action and template
	 get '/counter'	=> sub ($c) {


	 @@ counter.html.ep
	 Counter: <%= session 'counter'	%>

       Note that you should use	custom "secrets" in Mojolicious	to make	signed
       cookies really tamper resistant.

	 app->secrets(['My secret passphrase here']);

   File	uploads
       All files uploaded via "multipart/form-data" request are	automatically
       available as Mojo::Upload objects from "param" in
       Mojolicious::Controller.	And you	don't have to worry about memory
       usage, because all files	above 250KiB will be automatically streamed
       into a temporary	file. To build HTML forms more efficiently, you	can
       also use	tag helpers like "form_for" in

	 use Mojolicious::Lite -signatures;

	 # Upload form in DATA section
	 get '/' => 'form';

	 # Multipart upload handler
	 post '/upload'	=> sub ($c) {

	   # Check file	size
	   return $c->render(text => 'File is too big.', status	=> 200)	if $c->req->is_limit_exceeded;

	   # Process uploaded file
	   return $c->redirect_to('form') unless my $example = $c->param('example');
	   my $size = $example->size;
	   my $name = $example->filename;
	   $c->render(text => "Thanks for uploading $size byte file $name.");


	 @@ form.html.ep
	 <!DOCTYPE html>
	     %=	form_for upload	=> (enctype => 'multipart/form-data') => begin
	       %= file_field 'example'
	       %= submit_button	'Upload'
	     % end

       To protect you from excessively large files there is also a limit of
       16MiB by	default, which you can tweak with the attribute
       "max_request_size" in Mojolicious.

	 # Increase limit to 1GiB

   User	agent
       With Mojo::UserAgent, which is available	through	the helper "ua"	in
       Mojolicious::Plugin::DefaultHelpers, there's a full featured HTTP and
       WebSocket user agent built right	in. Especially in combination with
       Mojo::JSON and Mojo::DOM	this can be a very powerful tool.

	 use Mojolicious::Lite -signatures;

	 # Blocking
	 get '/headers'	=> sub ($c) {
	   my $url = $c->param('url') || '';
	   my $dom = $c->ua->get($url)->result->dom;
	   $c->render(json => $dom->find('h1, h2, h3')->map('text')->to_array);

	 # Non-blocking
	 get '/title' => sub ($c) {
	   $c->ua->get('' => sub	($ua, $tx) {
	     $c->render(data =>	$tx->result->dom->at('title')->text);

	 # Concurrent non-blocking
	 get '/titles' => sub ($c) {
	   my $mojo = $c->ua->get_p('');
	   my $cpan = $c->ua->get_p('');
	   Mojo::Promise->all($mojo, $cpan)->then(sub ($mojo, $cpan) {
	     $c->render(json =>	{
	       mojo => $mojo->[0]->result->dom->at('title')->text,
	       cpan => $cpan->[0]->result->dom->at('title')->text


       For more	information about the user agent see also "USER	AGENT" in

       WebSocket applications have never been this simple before. Just receive
       messages	by subscribing to events such as "json"	in
       Mojo::Transaction::WebSocket with "on" in Mojolicious::Controller and
       return them with	"send" in Mojolicious::Controller.

	 use Mojolicious::Lite -signatures;

	 websocket '/echo' => sub ($c) {
	   $c->on(json => sub ($c, $hash) {
	     $hash->{msg} = "echo: $hash->{msg}";
	     $c->send({json => $hash});

	 get '/' => 'index';


	 @@ index.html.ep
	 <!DOCTYPE html>
	       var ws =	new WebSocket('<%= url_for('echo')->to_abs %>');
	       ws.onmessage = function (event) {
		 document.body.innerHTML += JSON.parse(;
	       ws.onopen = function (event) {
		 ws.send(JSON.stringify({msg: 'I aY Mojolicious!'}));

       For more	information about real-time web	features see also "REAL-TIME
       WEB" in Mojolicious::Guides::Cookbook.

       You can use the Mojo::Log object	from "log" in Mojolicious to portably
       collect debug messages and automatically	disable	them later in a
       production setup	by changing the	Mojolicious operating mode, which can
       also be retrieved from the attribute "mode" in Mojolicious.

	 use Mojolicious::Lite -signatures;

	 # Prepare mode	specific message during	startup
	 my $msg = app->mode eq	'development' ?	'Development!' : 'Something else!';

	 get '/' => sub	($c) {
	   $c->app->log->debug('Rendering mode specific	message');
	   $c->render(text => $msg);

	 app->log->debug('Starting application');

       The default operating mode will usually be "development"	and can	be
       changed with command line options or the	"MOJO_MODE" and	"PLACK_ENV"
       environment variables. A	mode other than	"development" will raise the
       log level from "debug" to "info". All messages will be written to
       "STDERR"	by default.

	 $ ./ daemon -m	production

       Mode changes also affect	a few other aspects of the framework, such as
       the built-in "exception"	and "not_found"	pages. Once you	switch modes
       from "development" to "production", no sensitive	information will be
       revealed	on those pages anymore.

       Testing your application	is as easy as creating a "t" directory and
       filling it with normal Perl tests like "t/basic.t", which can be	a lot
       of fun thanks to	Test::Mojo.

	 use Test::More;
	 use Mojo::File	qw(curfile);
	 use Test::Mojo;

	 # Portably point to "../"
	 my $script = curfile->dirname->sibling('');

	 my $t = Test::Mojo->new($script);


       Just run	your tests with	prove.

	 $ prove -l -v
	 $ prove -l -v t/basic.t

       You can continue	with Mojolicious::Guides now or	take a look at the
       Mojolicious wiki	<>, which
       contains	a lot more documentation and examples by many different

       If you have any questions the documentation might not yet answer, don't
       hesitate	to ask in the Forum <> or the
       official	IRC channel "#mojo" on "" (chat	now!

perl v5.32.1			  2020-12-27  Mojolicious::Guides::Tutorial(3)


Want to link to this manual page? Use this URL:

home | help