Nonnative

Do you love building microservices using different languages?

Do you love testing applications using cucumber with ruby?

Well so do I. The issue is that most languages the cucumber implementation is not always complete or you have to write a lot of code to get it working.

So why not test the way you want and build the microservice how you want. These kind of tests will make sure your application is tested properly by going end-to-end.

The way it works is it spawns processes or servers you configure and waits for it to start. Then you communicate with your microservice however you like (TCP, HTTP, gRPC, etc)

Installation

Add this line to your application's Gemfile:

gem 'nonnative'

And then execute:

$ bundle

Or install it yourself as:

$ gem install nonnative

Usage

Configure nonnative with the following:

Process, Server or Service that you want to start.
A timeout value.
A time to wait.
Port to verify.
The class for servers.
The log for servers/processes
The strategy for processes, servers and services.

Strategy

The strategy can be one of the following values:

startup - When we include nonnative/startup, it will start it once.
before - When we tag our features with @startup it will start and stop after the scenario.
manual - When we tag our features with @manual it will stop after the scenario.

Processes

A process is some sort of command that you would run locally.

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.process do |p|
    p.name = 'start_1'
    p.command = -> { 'features/support/bin/start 12_321' }
    p.timeout = 5
    p.wait = 0.1
    p.port = 12_321
    p.log = 'reports/12_321.log'
    p.signal = 'INT' # Possible values are described in Signal.list.keys.
    p.environment = { # Pass environment variables to process.
      'TEST' => 'true'
    }
  end

  config.process do |p|
    p.name = 'start_2'
    p.command = -> { 'features/support/bin/start 12_322' }
    p.timeout = 0.5
    p.wait = 0.1
    p.port = 12_322
    p.log = 'reports/12_322.log'
  end
end

Setup it up through configuration:

version: 1.0
processes:
  -
    name: start_1
    command: features/support/bin/start 12_321
    timeout: 5
    wait: 0.1
    port: 12321
    log: reports/12_321.log
    signal: INT # Possible values are described in Signal.list.keys.
    environment: # Pass environment variables to process.
      TEST: true
  -
    name: start_2
    command: features/support/bin/start 12_322
    timeout: 5
    wait: 0.1
    port: 12322
    log: reports/12_322.log

Then load the file with

require 'nonnative'

Nonnative.configure do |config|
  config.load_file('configuration.yml')
end

With cucumber you can also verify how much memory is used by the process:

Then the process 'start_1' should consume less than '25mb' of memory

Servers

A server is a dependency to some external API.

Define your server:

module Nonnative
  class EchoServer < Nonnative::Server
    def perform_start
      @socket_server = TCPServer.new(service.host, service.port)

      loop do
        client_socket = @socket_server.accept
        client_socket.puts 'Hello World!'
        client_socket.close
      end
    rescue StandardError
    end

    def perform_stop
      @socket_server.close
    end
  end
end

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.server do |s|
    s.name = 'server_1'
    s.klass = Nonnative::EchoServer
    s.timeout = 1
    s.port = 12_323
    s.log = 'reports/server_1.log'
  end

  config.server do |s|
    s.name = 'server_2'
    s.klass = Nonnative::EchoServer
    s.timeout = 1
    s.port = 12_324
    s.log = 'reports/server_2.log'
  end
end

Setup it up through configuration:

version: 1.0
servers:
  -
    name: server_1
    class: Nonnative::EchoServer
    timeout: 1
    port: 12323
    log: reports/server_1.log
  -
    name: server_2
    class: Nonnative::EchoServer
    timeout: 1
    port: 12324
    log: reports/server_2.log

Then load the file with:

require 'nonnative'

Nonnative.configure do |config|
  config.load_file('configuration.yml')
end

HTTP

Define your server:

module Nonnative
  module Features
    class Application < Sinatra::Application
      configure do
        set :server_settings, log_requests: true
      end

      get '/hello' do
        'Hello World!'
      end
    end

    class HTTPServer < Nonnative::HTTPServer
      def app
        Application.new
      end
    end
  end
end

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.server do |s|
    s.name = 'http_server_1'
    s.klass = Nonnative::Features::HTTPServer
    s.timeout = 1
    s.port = 4567
    s.log = 'reports/http_server_1.log'
  end
end

Setup it up through configuration:

version: 1.0
servers:
  -
    name: http_server_1
    class: Nonnative::Features::HTTPServer
    timeout: 1
    port: 4567
    log: reports/http_server_1.log

Then load the file with:

require 'nonnative'

Nonnative.configure do |config|
  config.load_file('configuration.yml')
end

gRPC

Define your server:

module Nonnative
  module Features
    class Greeter < GreeterService::Service
      def say_hello(request, _call)
        Nonnative::Features::SayHelloResponse.new(message: request.name.to_s)
      end
    end

    class GRPCServer < Nonnative::GRPCServer
      def svc
        Greeter.new
      end
    end
  end
end

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.server do |s|
    s.name = 'grpc_server_1'
    s.klass = Nonnative::Features::GRPCServer
    s.timeout = 1
    s.port = 9002
    s.log = 'reports/grpc_server_1.log'
  end
end

Setup it up through configuration:

version: 1.0
servers:
  -
    name: grpc_server_1
    class: Nonnative::Features::GRPCServer
    timeout: 1
    port: 9002
    log: reports/grpc_server_1.log

Then load the file with:

require 'nonnative'

Nonnative.configure do |config|
  config.load_file('configuration.yml')
end

Services

A service is an external dependency to your system. This is usually an expensive process to start like a DB and you would prefer to be managed externally. Services are not really exciting by themselves, it's when we add proxies that they allow us to do some extra work.

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.service do |s|
    s.name = 'postgres'
    p.port = 5432
  end

  config.service do |s|
    s.name = 'redis'
    s.port = 6379
  end
end

Setup it up through configuration:

version: 1.0
processes:
  -
    name: postgres
    port: 5432
  -
    name: redis
    port: 6379

Then load the file with

require 'nonnative'

Nonnative.configure do |config|
  config.load_file('configuration.yml')
end

Proxies

We allow different proxies to be configured. These proxies can be used to simulate all kind of situations. The proxies that can be configured are:

none (this is the default)
fault_injection

Processes

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.process do |p|
    p.proxy = {
      kind: 'fault_injection',
      port: 20_000,
      log: 'reports/proxy_server.log',
      options: {
        delay: 5
      }
    }
  end
end

Setup it up through configuration:

version: 1.0
processes:
  -
    proxy:
      kind: fault_injection
      port: 20000
      log: reports/proxy_server.log
      options:
        delay: 5

Servers

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.server do |s|
    s.proxy = {
      kind: 'fault_injection',
      port: 20_000,
      log: 'reports/proxy_server.log',
      options: {
        delay: 5
      }
    }
  end
end

Setup it up through configuration:

version: 1.0
servers:
  -
    proxy:
      kind: fault_injection
      port: 20000
      log: reports/proxy_server.log
      options:
        delay: 5

Services

Setup it up programmatically:

require 'nonnative'

Nonnative.configure do |config|
  config.service do |s|
    s.proxy = {
      kind: 'fault_injection',
      port: 20_000,
      log: 'reports/proxy_server.log',
      options: {
        delay: 5
      }
    }
  end
end

Setup it up through configuration:

version: 1.0
services:
  -
    proxy:
      kind: fault_injection
      port: 20000
      log: reports/proxy_server.log
      options:
        delay: 5

Fault Injection

The fault_injection proxy allows you to simulate failures by injecting them. We currently support the following:

close_all - Closes the socket as soon as it connects.
delay - This delays the communication between the connection. Default is 2 secs can be configured through options.
invalid_data - This takes the input and rearranges it to produce invalid data.

Processes

Setup it up programmatically:

name = 'name of process in configuration'
server = Nonnative.pool.process_by_name(name)

server.proxy.close_all # To use close_all.
server.proxy.reset # To reset it back to a good state.

With cucumber:

Given I set the proxy for process 'process_1' to 'close_all'
Then I should reset the proxy for process 'process_1'

Servers

Setup it up programmatically:

name = 'name of server in configuration'
server = Nonnative.pool.server_by_name(name)

server.proxy.close_all # To use close_all.
server.proxy.reset # To reset it back to a good state.

With cucumber:

Given I set the proxy for server 'server_1' to 'close_all'
Then I should reset the proxy for server 'server_1'

Services

Setup it up programmatically:

name = 'name of service in configuration'
service = Nonnative.pool.service_by_name(name)

service.proxy.close_all # To use close_all.
service.proxy.reset # To reset it back to a good state.

With cucumber:

Given I set the proxy for service 'service_1' to 'close_all'
Then I should reset the proxy for service 'service_1'

Go

As we love using go as a language for services we have added support to start binaries with defined parameters. This expects that you build your services in the format of command sub_command --params

To get this to work you will need to create a main_test.go file with these contents:

// +build features

package main

import "testing"

func TestFeatures(t *testing.T) {
	main()
}

Then to compile this binary you will need to do the following:

go test -mod vendor -c -tags features -covermode=count -o your_binary -coverpkg=./... github.com/your_location

Setup it up programmatically:

tools = %w[prof trace cover]

Nonnative.go_executable(tools, 'reports', 'your_binary', 'sub_command', '--config config.yaml')

Setup it up through configuration:

version: 1.0
processes:
  -
    name: go
    go:
      tools: [prof, trace, cover]
      output: reports
      executable: your_binary
      command: sub_command
      parameters:
        - --config config.yaml
    timeout: 5
    port: 8000
    log: reports/go.log

nonnative
Release 1.79.0

Release 1.79.0

1.79.0

1.78.0

1.77.0

1.76.0

1.75.0

1.74.1

1.74.0

1.73.0

1.72.0

1.71.0

Documentation

Nonnative

Installation

Usage

Strategy

Processes

Servers

HTTP

gRPC

Services

Proxies

Processes

Servers

Services

Fault Injection

Processes

Servers

Services

Go

Stats

Development practices

Releases

Maintainers

Contributors

nonnative Release 1.79.0

Release 1.79.0 Toggle Dropdown 1.79.0 1.78.0 1.77.0 1.76.0 1.75.0 1.74.1 1.74.0 1.73.0 1.72.0 1.71.0

Documentation

Nonnative

Installation

Usage

Strategy

Processes

Servers

HTTP

gRPC

Services

Proxies

Processes

Servers

Services

Fault Injection

Processes

Servers

Services

Go

Stats

Development practices

Releases

Maintainers

Contributors

nonnative
Release 1.79.0

Release 1.79.0

1.79.0

1.78.0

1.77.0

1.76.0

1.75.0

1.74.1

1.74.0

1.73.0

1.72.0

1.71.0