GitHub
Tests: 12 • Commercial: 2 • Pet projects: 4 • Legacy: 4
Total: 22

.NET Framework

Test
2021

Project Request

ASP.NET MVC • C# • SQL Server
Idea of the project: if someone wants to order a project development, here you can send an application.
Test
2020

ProjectC

ASP.NET MVC • C# • JSON • jQuery
JSON data processing.
Test
2020

Vehicle Maintenance

ASP.NET MVC • VB.NET • JSON
Idea of the project: if someone wants to order a project development, here you can send an application.
Test
2019

Movie Navigator

ASP.NET MVC • VB.NET
Request information about movie from IMDB.
Test
2018

Customers Exchange

ASP.NET MVC • C# • SQL Server
Automated teller machine emulation.
Test
2016

ATM

ASP.NET MVC • C#
Automated teller machine emulation.

.NET Core

Pet project
2022

Mail Daemon

.NET 9 • Console • JSON
Utility to send mails with customizable settings.

Custom

Code
2024

Buns of code

.NET Framework • C# • JavaScript
Code snippets from my projects, ready to use; tiny tests; code examples.

PHP

Test
2024

Mediabox

PHP 8 • Laravel 11 • Vue.js • Composer • SQLite
Test project for media files management.
Test
2020

Loan Castle

PHP • MariaDB
Jums jāizstrādā kāda lielāk projekta prototips. Izstrādājot prototipu, paturiet prātā, ka projektam attīstoties, šo prototipu varētu vajadzēt pilnveidot.
Test
2020

Content Management

PHP • MySQL • AJAX
Создать простой сайт, где будет страница с формой для авторизации и страница для авторизованного пользователя.
Test
2019

Laravel

PHP • Laravel • Vue.js • Composer • SQLite
Izveidot aplikāciju, kura ik pēc noteikta intervāla (60 sekundes) veic ierakstu datubāzē izmantojot Laravel freimworka iebūvēto funkcionalitāti.
Test
2019

Phone Check

PHP • JavaScript • JSON • Docker
Implement application to detect country by phone number.

Frontend

Test
2021

Forex Wall

npm • React
For this exercise, what we need is a simple live wall for tracking currencies.

Business projects

Commercial
2008

Certification Center

.NET Framework 4.8 • ASP.NET Web Forms • C# • LINQ • SQL Server • ADO.NET • Dapper • JavaScript • jQuery • Git
Transport registration and certification services in Latvia, Customer Relationship Management.
Commercial
2000

Amerikas Auto

.NET Framework 4.8 • ASP.NET Web Forms • C# • LINQ • SQL Server • ADO.NET • Entity Framework • JavaScript • jQuery • Git
Car service and spare parts for all USA and European car models, Customer Relationship Management.

Pet projects

Pet project
2023

Geolocation Assistant

.NET 8 • ASP.NET Core • C# • Web API • JSON • Git
Website for determining geolocation by IP or geotagged photo.
Pet project
2008

Web Dynamics

.NET Framework 4.8 • ASP.NET Web Forms • C# • LINQ • Web API • JSON • SQL Server • Dapper • JavaScript • jQuery • SVG • Git
Software development blog. Articles, books, videos, content management.
Pet project
2000

Blackball

.NET Framework 4.8 • ASP.NET Web Forms • C# • LINQ • Web API • JSON • XML • SQL Server • Dapper • JavaScript • jQuery • SVG • Git
My entertainment portal created from scratch.

Good old times

Legacy
2000

DOS Clock

Turbo Pascal • Assembler
Digital clock.
Legacy
2000

BrainOut

Turbo Pascal • Assembler
Tank battle game.
Legacy
1999

Airport Administrator

Turbo Pascal
Курсовая работа в институте.
Legacy
1998

Atomizer

Turbo Pascal • Assembler
Atomizer, aka «Studio2D». Graphic raster editor. AGI is my own «Atomizer Generated Image» file format.

Mediabox

2024 Test

Test project for media files management.

PHP 8 Laravel 11 Vue.js Composer SQLite
Information
Source code
  app
  Http
  .bin
  vite
  lib
  dist
  esm
  node
  lib
  core
  env
  node
  lib
  lib
  lib
  lib
  dist
  lib
  lib
  dist
  es
  lib
  vite
  dist
  node
  dist
  css
  js
  app
  data
  logs
  Unit
  math
  src
  src
  src
  docs
  en
  lib
  src
  src
  Cron
  src
  src
  Core
  ORM
  Spot
  filp
  src
  css
  js
  Util
  src
  src
  src
  src
  psr7
  src
  src
  Core
  Text
  Type
  Xml
  Core
  Text
  Type
  Xml
  src
  Auth
  make
  Bus
  View
  Auth
  Bus
  Http
  Mail
  View
  Auth
  Bus
  Http
  dist
  Http
  Json
  Log
  Mail
  html
  text
  Jobs
  lang
  en
  View
  pint
  pint
  src
  sail
  8.0
  8.1
  8.2
  8.3
  src
  src
  src
  src
  Node
  Util
  Node
  Node
  Node
  Data
  Node
  Node
  Util
  Xml
  src
  src
  src
  docs
  Pass
  src
  Curl
  Test
  src
  Date
  Spl
  lazy
  src
  Cli
  Lang
  List
  src
  src
  lib
  Node
  Expr
  Cast
  Name
  Stmt
  src
  src
  Html
  src
  xml
  src
  src
  src
  Data
  Node
  Html
  css
  js
  Xml
  Util
  src
  src
  src
  src
  src
  Test
  Test
  Math
  Type
  Api
  Rule
  Stub
  Api
  PHPT
  Cli
  Xml
  Util
  PHP
  Xml
  psr
  src
  src
  src
  src
  src
  docs
  src
  log
  src
  src
  psy
  src
  Hoa
  77
  78
  Sudo
  Util
  src
  src
  Map
  Tool
  uuid
  src
  Time
  Guid
  Lazy
  Math
  Dce
  Node
  Time
  Type
  src
  src
  src
  src
  src
  diff
  src
  src
  src
  src
  src
  src
  src
  src
  type
  src
  type
  src
  Test
  CI
  Node
  css
  js
  File
  Test
  Log
  Test
  Smtp
  Auth
  mime
  Part
  Test
  Test
  data
  data
  Test
  Util
  Test
  uid
  css
  js
  Test
  yaml
  Tag
  src
  src
  Css
  Rule
  src
  File
  Util
  voku
  src
  voku
  data
  src
  .env
Root / vendor / mockery / mockery / docs / reference / spies.rst
.. index:: single: Reference; Spies Spies ===== Spies are a type of test doubles, but they differ from stubs or mocks in that, that the spies record any interaction between the spy and the System Under Test (SUT), and allow us to make assertions against those interactions after the fact. Creating a spy means we don't have to set up expectations for every method call the double might receive during the test, some of which may not be relevant to the current test. A spy allows us to make assertions about the calls we care about for this test only, reducing the chances of over-specification and making our tests more clear. Spies also allow us to follow the more familiar Arrange-Act-Assert or Given-When-Then style within our tests. With mocks, we have to follow a less familiar style, something along the lines of Arrange-Expect-Act-Assert, where we have to tell our mocks what to expect before we act on the SUT, then assert that those expectations were met: .. code-block:: php // arrange $mock = \Mockery::mock('MyDependency'); $sut = new MyClass($mock); // expect $mock->shouldReceive('foo') ->once() ->with('bar'); // act $sut->callFoo(); // assert \Mockery::close(); Spies allow us to skip the expect part and move the assertion to after we have acted on the SUT, usually making our tests more readable: .. code-block:: php // arrange $spy = \Mockery::spy('MyDependency'); $sut = new MyClass($spy); // act $sut->callFoo(); // assert $spy->shouldHaveReceived() ->foo() ->with('bar'); On the other hand, spies are far less restrictive than mocks, meaning tests are usually less precise, as they let us get away with more. This is usually a good thing, they should only be as precise as they need to be, but while spies make our tests more intent-revealing, they do tend to reveal less about the design of the SUT. If we're having to setup lots of expectations for a mock, in lots of different tests, our tests are trying to tell us something - the SUT is doing too much and probably should be refactored. We don't get this with spies, they simply ignore the calls that aren't relevant to them. Another downside to using spies is debugging. When a mock receives a call that it wasn't expecting, it immediately throws an exception (failing fast), giving us a nice stack trace or possibly even invoking our debugger. With spies, we're simply asserting calls were made after the fact, so if the wrong calls were made, we don't have quite the same just in time context we have with the mocks. Finally, if we need to define a return value for our test double, we can't do that with a spy, only with a mock object. .. note:: This documentation page is an adaption of the blog post titled `"Mockery Spies" <https://davedevelopment.co.uk/2014/10/09/mockery-spies.html>`_, published by Dave Marshall on his blog. Dave is the original author of spies in Mockery. Spies Reference --------------- To verify that a method was called on a spy, we use the ``shouldHaveReceived()`` method: .. code-block:: php $spy->shouldHaveReceived('foo'); To verify that a method was **not** called on a spy, we use the ``shouldNotHaveReceived()`` method: .. code-block:: php $spy->shouldNotHaveReceived('foo'); We can also do argument matching with spies: .. code-block:: php $spy->shouldHaveReceived('foo') ->with('bar'); Argument matching is also possible by passing in an array of arguments to match: .. code-block:: php $spy->shouldHaveReceived('foo', ['bar']); Although when verifying a method was not called, the argument matching can only be done by supplying the array of arguments as the 2nd argument to the ``shouldNotHaveReceived()`` method: .. code-block:: php $spy->shouldNotHaveReceived('foo', ['bar']); This is due to Mockery's internals. Finally, when expecting calls that should have been received, we can also verify the number of calls: .. code-block:: php $spy->shouldHaveReceived('foo') ->with('bar') ->twice(); Alternative shouldReceive syntax ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ As of Mockery 1.0.0, we support calling methods as we would call any PHP method, and not as string arguments to Mockery ``should*`` methods. In cases of spies, this only applies to the ``shouldHaveReceived()`` method: .. code-block:: php $spy->shouldHaveReceived() ->foo('bar'); We can set expectation on number of calls as well: .. code-block:: php $spy->shouldHaveReceived() ->foo('bar') ->twice(); Unfortunately, due to limitations we can't support the same syntax for the ``shouldNotHaveReceived()`` method.