DEV Community: Alex Lunkov

Mock server

Alex Lunkov — Sat, 21 Sep 2024 16:35:50 +0000

Hi everyone

Recently I encountered with a need to have a mock http server for local development, where I can configure paths and responses. Definitely I found few interesting solutions, in some of them I have to write code, some of them were a bit overcomplicated and difficult to use. Definitely I did not find something what I can easily configure, like set a path with a specific HTTP method and set a response with a status code and response body. I need just easy configuration.

So... I had some time in the evening :)

I've prepared a repository go-mock-server

I used Go programming language for the implementation. To run a mock server it is just required to create a YAML file and specify list of endpoints with desired HTTP methods on an endpoint and specify a response, like a predefined string or a file in a storage. There are two ways to launch the go-mock-server. The simplest is to use Docker - the repo contains a Docker file, so it is not needed to install Go on your machine, just mount a folder with your configuration file and that is it. Another way is to use Go to run the server.

An example of configuration

port: 8081
endpoints:
  - path: /{$}
    response-body: file:model/responses/index.html
    headers:
      content-type: 
        - text/html; charset=utf-8

  - path: /test
    # no method or empty array equals to all methods
    method: [get, post, put, delete]
    response-body: > 
      {"test": 1}
    headers:
      content-type: 
        - application/json

  - path: /download
    method: [get]
    response-body: file:model/responses/download/file.txt
    headers:
      content-type: 
        - application/octet-stream

  - path: /redirect
    method: [get]
    status-code: 301
    headers:
      location: 
        - https://google.com

Storing a Java collection in a file storage

Alex Lunkov — Thu, 15 Feb 2024 11:02:09 +0000

If you deal with a large datasets stored in a Java collection, lets say java.util.List, sooner or later you would encounter with a situation that allocated memory is not enough to hold all your data. It may be even small number of elements in a collection, but many of them take much of memory. It happens that a process must accumulate large dataset, and there is no way to process data in chunks to fit allocated memory. There are multiple ways to resolve an issue, from storing data in a file to temporarily store data in Redis.

We encountered with similar issue in a system which is developed for many years, and it is not so simple just to change way how data is accumulated in memory and utilized. A Java collection is full of large objects and there are multiple threads in the same app for that specific activity. Of course, there are few instances of a service which processes data, sometimes a dataset is small, sometimes a dataset is large and that is really frustrating, it is not simple to choose a scaling model. In such cases I usually say - simpler, faster, and more reliable to rewrite rather than "fine-tune", but this time we do fine-tuning :) Let's leave behind a curtain why a system operates with data which does not fit allocated memory 🤠 it happens. Sometimes we can change an implementation in more robust way, but sometimes we need to find a compromise with existing solution.

We implemented a small library: a Java collection data is stored in a file system instead of RAM and a convenient, Java Stream like interface for operating on data is provided.

Okay, the library - FStream. A central class FCollection which is similar to java.util.List but with reduced number of methods. With FCollection you can add new items, sort them with a comparator, iterate elements, and create a instance of FStream which is also reduced version of Java Stream. With FStream you can apply sequential operations on elements of a collection.

Example

See, in following code snapshot all data is stored in a file located in a temporary directory. Data is written to a file system immediately as data is added. But it it possible to operate on the items over FStream.

FCollection<SomeClassName> collection = FCollection.create();

// add elements to a collection
collection.add(instance);

// iterate elements of a collection
Iterator<SomeClassName> i = collection.iterator();
while (i.hasNext()) {
    consumer.accept(i.next());
}

// also iterates over all elements in a collection
collection.forEach(this::consumer);

// create a new collection
FCollection<AnotherClassName> collection2 = collection.stream()
        .filter(o -> o.isActive() == true)
        .map(this::convert)
        .sort((o1, o2) -> o1.compareTo(o2))
        .collect();

// destroy collections' data in a file storage
collection.close();
collection2.close();

How it works

Create a collection

When a collection is created, for instance with a method create, then a new file is created in a /tmp directory or in a custom directory if specified.

FCollection<SomeClassName> collection = FCollection.create();

Add items in a collection

Adding operation of a new item to a collection consists of an item serialization and writing to a collection's file in a file storage. Serialization is done by default with a FJdkSerializer, but it is possible to use a custom serializer. Customization is described below.

// add elements to a collection
collection.add(instance);

Apply operations on a collection

An approach here is absolutely the same with Java Stream - a developer can specify operations takes on each element of a collection in a function way. As result, a new collection is created, stored in a file storage.

FCollection<AnotherClassName> collection2 = collection.stream()
        .filter(o -> o.isActive() == true)
        .map(this::convert)
        .sort((o1, o2) -> o1.compareTo(o2))
        .collect();

Customization

So far it is possible to specify where to store temporary data of a collections, and assign a custom serializer for a collection. A serializer must implement FSerializer interface. After that a collection can be created with a builder.

FCollection<String> c = 
        FCollection.builder()
        .serializer(new CustomSerializer())
        .storageLocation("/your/location")
        .build();

Want to try it out?

Visit project's GitHub repository: https://github.com/rootmach/fstream

What is it like to develop applications using Golang when you have experience with Java?

Alex Lunkov — Mon, 18 Dec 2023 17:50:11 +0000

What is it like to develop applications using Golang when you have experience with Java?

Hi everyone. In this article I would like to collect few aspects of software development with Golang from point of view of a Software Developer/Architech. I have experience with Java since 2005 when I started to use sometimes the language for server-side application having experience already with C/C++. Few years ago I started to use Golang as well as few other languages at daily work and I would say that I definitely like the philosophy of the Golang. I cannot say that I like absolutely everything in Golang, but definitely I would use the language more. The article is not about use cases when to use Golang, but more about how to use different software development techniques, which are used in Java (and other languages as well). What does it take to use Test Driven Development and Behavior Driven Development with Golang? In my opinion TDD and BDD are the most important approaches in software development and knowledge sharing. In this article I wanted to share my personal experience which I've got when I was making first steps in Golang few years ago. I'd started to work with a huge application written completely in Golang - it really does not matter why the application was big and monolith, sometimes we have to maintain and develop decisions especially if such a thing appears before you join a team/company.

Test Driven Development with Golang

Of course Test Driven Development is possible with Golang and sometimes is more comfortable comparing with Java. In overall functional nature of Golang requires writing a bit less code then in Java. Quite interesting thing - Golang provides out-of-the-box testing framework as part of language. It is quite good, especially if you are fine with basic assert___ matchers - no need to search for something special. I believe majority of Java projects are tested with usage of JUnit 4/5 as a basic testing framework, but JUnit is not part of Java :) Lets see the same function Add written and tested in Java and Golang.The does not do anything special - just adds one number to another and returns a result.

For example Golang:

func Add(one int, two int) int {
    return one + two
}

func TestAdd(t *testing.T) {
    result := Add(1, 2)
    assert.Equal(t, 3, result)
}

Comparing with Java code:

public class Calculator {
    public int add(int one, int two) {
        return one + two
    }
}
public class CalculatorTest {
    @Test
    public void test() {
        Calculator c = new Calculator();
        int result = c.add(1, 2);
        assertEquals(3, result);
    }    
}

Mocking with Golang

The most interesting part of unit testing is mocking. Java library Mockito manipulates with Java code to create mocks or a developer can derive a basic interface and few implementations from the interface where one of which can be a mock which is used in unit tests. In overall mocking in Java is something really simple and useful.

public class Calculator {
    public int add(int one, int two) {
        return one + two;
    }
}
public class Numbers {
    private final Calculator c;

    public Numbers(Calculator c) {
        this.c = c;
    }

    public int makeAddition() {
        return c.add(1, 2);
    }
}

// unit test
public class NumbersTest {
    final Calculator mock = mock(Calculator.class);
    final Numbers subject = new Numbers(mock);

    @Test
    public void testMakeAddition() {
        when(mock.add(1,2)).thenReturn(3);

        int result = subject.makeAddition();

        assertEquals(3, result);
        verify(mock, times(1)).add(1,2);
    }
}

It is completely different in Golang - the language itself does not offer anything similar to bytecode manipulation as Java offers OOB. Usual approach in Golang is to use interfaces and supply one implementation with business logic and another mocked.

// basic interface
type Calculator interface {
    Add(one int, two int) int
}

type CalculatorImpl struct{}

func (c *CalculatorImpl) Add(one int, two int) int {
    return one + two
}

// Usage
func MakeAddition(c Calculator) int {
    return c.Add(1, 2)
}

And now we want to test MakeAddition function. With interface it is really simple - just introduce your mock implementation.

type CalculatorMock struct {
    AddExpectedValue int
}

func (c CalculatorMock) Add(one int, two int) int {
    // here also possible to record input parameters and verify them later.
    return c.AddExpectedValue
}

func TestMakeAddion(t *testing.T) {
    mock := CalculatorMock{3}

    result := MakeAddition(mock)
    assert.Equal(t, 3, result)
}

It looks more cumbersome comparing to Java, but acceptable. There is mocking tools for Golang and it seems from a description it covers much of the need - Uber GO

Behavior Driven Development with Golang

Here everything is fine - there is implementation of Cucumber in Golang and it means it is possible use BDD in Golang. Of course it is possible to use different framework written not with Golang, in some cases it would considered even as plus:

a client of project's API cannot reuse anything from Golang project's code and has to use API as a black box;
QA team/regular developers can create BDD scenarios independently from project's code and do not intersect codebase of QA project and Golang project.

As a conclusion

It is possible to use the same software development techniques in Golang as used in Java. Definitely there are differences, it is expected, but it is relatively simple to use similar features, like mocking, write code in TDD/BDD way in Golang. I really like how it is done in Golang!

Resources

As an example I've created a demo application written with Golang Simple Golang application. The application exposes a REST API, connects to Postgres database and Redis, has unit and integration tests. The application just summarizes thoughts written in this article.

Dependency injection and unit testing

Alex Lunkov — Wed, 26 Oct 2022 20:06:35 +0000

Any developer, who works with object-oriented programming language and writes unit tests for implementations, encounters with a choice how to provide dependencies to a class. Some languages provide few choices, some languages provide just one way via constructor arguments.

Let's take a Java language as an example, where dependencies can be provided in two ways and how writing unit tests can be different in both cases. What pros and cons could each approach has.

So, our tasks could look like:

class fields must be assigned with corresponding instances;
a unit test should be written.

Here is our initial code snippet to be modified. The code snippet has one dependency to be populated in runtime.

public class Service {

    Dependency dependency;

    public void action() {
        dependency.action();
    }

}

Assign dependencies to class field by DI framework

A sample above can be changed in something like this if we use for instance Spring framework.

@Component
public class Service {

    @Autowired
    private Dependency dependency;

    public void action() {
        dependency.action();
    }

}

Looks quite sharp, nothing "redundant". Few things bother me here.

The first thing - Java reflection is used to assign dependencies. Not a big deal, but providing a value to a private field somehow in background does not look really simple and clean - private fields should be assigned from the inside of a class only.

The second thing - fields of the class are not final. Technically, it means that fields can be modified from the inside of the class during a life cycle of an instance of the class. In other words, the class partially looses immutability and that is not good - state changes and behavior changes as well. It would be difficult to write a good and clean unit test.

Okay, so far it does not look too bad, but let's try to write a unit test for an implementation above.

Here are tasks for a unit test:

assign a dependency to a class field;
check if a dependency's method is actually called.

Current implementation does not suppose direct assignment of dependencies to class fields, so we would use DI to assign instance of a dependency to a private class field. It is possible to do it with only mockito extension or mockito + Spring testing extension. Each way has pros and cons, but as result a dependency will be assigned to a desired field, and we are able to write a unit test to verify our implementation.

@ExtendWith(MockitoExtension.class)
class ServiceTest {

    @Mock
    private Dependency dependency;

    @InjectMocks
    private Service subject;

    @Test
    public void testAction() {
        subject.action();

        verify(dependency, times(1)).action();
    }

}

I would highlight that it is quite smooth way: initialization and assignment happens invisibly. The only one thing - we need a mediator to be able to mock and assign instances to class fields. We do not see and control how and when mocking and assignment happen. This fact already makes such approach a bit foggy: looks like we "see" everything, but not clearly. Shapes in fog can be tricky ;)

Assign dependencies to class field via a class constructor by DI framework

Let's check out another way of providing dependencies - via class constructor. A sample Java class can be transformed in a following form.

@Component
public class Service {

    private final Dependency dependency;

    public Service(Dependency dependency) {
        this.dependency = dependency;
    }

    public void action() {
        dependency.action();
    }

}

All dependencies are provided via a constructor explicitly, class fields are marked as final and are immutable during entire life cycle of an instance of a class. Maybe constructor takes more space in a class definition just because we use it for assigning dependencies.

Let's write a unit test for such implementation and follow the same tasks as for wiring dependencies via DI directly to class fields:

assign a dependency to a class field;
check if a dependency's method is actually called.

class ServiceTest {

    private final Dependency dependency = mock(Dependency.class);

    private final Service subject = new Service(dependency);

    @Test
    public void testAction() {
        subject.action();

        verify(dependency, times(1)).action();
    }

}

Since we pass dependencies to a class via constructor we can use following approach above. Test implementation does not require any special extension to run a test: dependency and test subject creation happens "manually". Such implementation has no invisible actions, everything is controlled by us. Implementation looks in different way, dependency creation is visible, passing dependencies is visible also, code is a bit longer than a previous implementation. Definitely it is more obvious what happens here.

Why `final` matters here?

A keyword final applied to a class field indicates immutability. If a class field has no such keyword there is a possibility to modify value of a class field. That means in some specific cases our class technically can behave differently, and it is not good at all - it is a way to produce problems in production rather than favor. Since a class looses immutability then unit testing results get unpredictable and can be described as flaky. So, final makes an object immutable, unit tests produce the same results, and application in production behaves as it is intended to.

Conclusion

Essential part of unit testing is simplicity and stability :) Simplicity facilitates easy understanding of implementation,
stability provides the same results in multiple invocation, and both lead to stable work in production. Considering approaches from the above, I would personally choose the second one. As of me it looks more simple, clean and straightforward. The second has no "magic" in tests - everything is on a table.

Sources

https://github.com/rootmach/dependency-injectuion-and-unit-testing

Handler - why small implementation is good?

Alex Lunkov — Tue, 11 Oct 2022 08:37:31 +0000

Controller, mouse event listner, message consumer and similar entities are types of a handler. A handler simply accepts input, optionally makes a decision if possible to proceed with received input data, converts input to a suitable format, and calls an underlying procedure.

The main question here is - how large can be a handler, what kind of logic a handler could contain?

Let's describe what a handler can be and do.

A software application and a handler

Software application is computer program designed to carry specific task. A user/client can communicate with an application via a user interface or via network calls, like REST, message queue, etc. So, it means each application has a layer which is responsible for accepting user's/client's input, verifying input, calling a specific procedure inside an application, and finally return output. Usually that layer is called a handler. Handler can be a REST controller with a set of endpoints, a keyboard or mouse event listener, a consumer for a message queue, a command-line arguments' parser and so on.

The main role of a handler is to accept and validate input data, prepare data from input for calling a procedure, make a decision if possible to proceed, call the procedure, and return result of procedure invocation if any.

So, the role of a handler is to provide a way to communicate with an application, which usually consists of multiple libraries. Technically, it should not be difficult to provide to a user/client different interfaces to communicate with an application, but in different ways.

It should be quite similar, if an application exposes REST or SOAP, Protobuf interface or anything similar to call the same procedure. Corresponding handler just accepts input data, prepares required input for a procedure, and calls a procedure.

| Handlers                             | Procedures               |
+--------------------------------------+--------------------------+
|                                      |                          |
+----------+                           |                          |
| REST     |-------+                   |                          |
+----------+       |                   |                          |
| Thrift   |-----+ |                   |                          |
+----------+     | |                   |                          |
| Protobuf |-----+-+------<-------->---| application's procedure  |
+----------+     | |     output/input  |                          |
|   ....   |-----+ |                   |                          |
+----------+       |                   |                          |
| RMI      |-------+                   |                          |
+----------+                           |                          |
|                                      |                          |
+--------------------------------------+--------------------------+
| Other Handlers                       | Other procedures         |
+--------------------------------------+--------------------------+

How much logic should contain a handler?

To answer that question we would consider few aspects:

Single responsibility principle from OOP design
Testability

Probably even the second aspect is already redundant if consider only "Single responsibility principle". The principle is described as following at oodesign.com

A responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes.

It means if a handler contains validating input, validating authentication, preparing other parameters for a procedure call, converting output, then such implementation clearly violates of a "Single responsibility principle". It is much better to move out logic, which does not belong to a handler explicitly, to abstractions or input processing chains.

From prospective of testing a handler that has long and complicated implementation with many dependencies is a nightmare :) Using Test-driven development and keeping in mind "Single responsibility" principle helps to create small enough which is easy to test and comply to OOP design patterns.

Very good example of such architecture is Spring Boot - validation can be done by providing special annotation on DTO filters handle an authentication and assign all the parameters required by a context to a request attributes which can be easily used in a handler. Validation rules are subject of unit tests and can be tested separately, but definitely we should check if desired validation rules are applied on a handler level.

A handler becomes easy to test - all what we need to test is how a controller accepts input data, fails/succeeds on validation, and if output complies expected format. The rest of the things are tested separately by unit tests and finally by integration tests.

Conclusion

Keep handler's implementation small, keep in mind OOP design principles, and optionally try to use Test-driven development as it facilitates keeping an implementation small and easy to test.

How to calculate thread pool size in Java

Alex Lunkov — Wed, 29 Jun 2022 19:51:23 +0000

"How many thread to use in an executor pool: 22, 50, or 10?" - similar questions were asked many times when a thread pool is created, and we need to choose a number of threads in a pool. If we choose too big number of threads then it could end up with exhausting resources, CPU, memory. If we choose too small number of threads then throughput of a system will be poor as CPU/memory is not used enough.

To choose properly number of threads for a threads pool we need to understand what type of tasks a thread pool will work with.
In general, all possible tasks can be divided into two groups:
compute-intensive tasks or CPU Bound tasks, I/O tasks or I/O Bound tasks.

Compute-intensive tasks (CPU bound)

Compute-intensive tasks in general are tasks when a CPU is constantly loaded with work and CPU idle time is much shorter comparing with usage time.

CPU | C         | W | C         | W | C         | W | C... 
    |-----------|---|-----------|---|-----------|---|-------->
                                                             Time

where C - compute time on CPU, W - idling time of CPU, waiting for a work.

In case of compute-intensive tasks a system usually achieves optimum utilization with a thread pool size calculated by a formula below.

Threads count = N + 1

where N - number of CPU cores in a machine, which can obtained in Java with Runtime.getRuntime().availableProcessors()

So, if a system has four CPU cores, then optimal maximum number of threads should be five.

I/O tasks (I/O Bound)

I/O tasks are tasks which involve a lot of communications with different applications on another a machine via network call. For example, when a thread runs a Http request to a remote system or fetches data from a database. I/O tasks are characterised with short processing time and longer idling time - CPU is less loaded with work and a thread waits for data to be obtained from a different machine.

CPU    | C | W     | C | W | C    | W | C... 
       |---|-------|---|---|------|---|-------->
                                               Time

where C - compute time on CPU, W - idling time of CPU, waiting for a work.

In case of I/O tasks

Threads count = N * U * (1 + W/C)

where
N - number of CPU cores in a machine, which can obtained in Java with Runtime.getRuntime().availableProcessors()
U - target CPU utilization and 0 <= U <= 1
W/C - ratio of wait time (W) to compute time (C)

Let's calculate following example:

a system has four CPU cores, so N = 4;
we target 100% CPU utilization, so U = 1;
we can estimate roughly for a request waiting time 100ms (W) and real calculating time is about 20ms (C).

Then we should expect that threads count should 20
as 4 * 1 * 100/20 = 20.

Conclusion

This article describes in general an idea of how to calculate an optimal thread pool size. It would happen that thread pool size should be even greater than calculated one by a formula. Quite many aspects affect thread pool size, like if other applications are working on the same machine and how much CPU time that applications are consuming.

I would highlight that formulas give us an estimate size of a thread pool that should be verified in test and later in a production environment by observing CPU utilization.

Test-driven development — I’m feeling lucky

Alex Lunkov — Sat, 20 Nov 2021 19:04:37 +0000

Intro

I have discussions from time to time with different developers and project managers about a software development process and suggest to use Test-driven development approach as the most effective process with explanation why it is better to use. Mainly, I see that people are very excited about the approach and welcome Test-driven development.

Only sometimes I encounter with a situation as in a picture above ⇈ — either developers or managers do not even want to hear about Test-driven development approach and argue is tough. Usually an argument that “Writing tests are taking too much time… It is impossible to meet deadlines writing tests… Clients do not want to pay for tests” prevails as the final answer in a discussion to use Test-driven development or not. But is it really true that writing tests slows down project’s movement, preventing fast releases, and taking much time?

Typical development process

Let's take a look at a typical development process of a new feature or modifying an existing one:

Define requirements;
Write code;
Validate the implementation;
Perform a regression testing.

First two items are the same for every project if a project has tests or not, but last two items are quite interesting and different when a project has tests or not. Let’s describe different in items 3 and 4 for two cases: a project has no tests and a project has tests.

A project has no tests

Validate the implementation usually means that a developer manually validates if an implementation of a newly added feature in the project. It is kind of a smoke test — just to see if nothing is broken in a project, it can be compiled, packaged, and run. If a developer sees a desired result then that is it — an implementation is done. All validations here are manual. Of course, internal implementation is known to a developer only and there is no understanding about boundaries.

A QA team should do the rest of validations — validate if a new feature works well externally. Internal validation usually is not a subject. Validation is a complex implementation is a hard and time-consuming task — check if memory used and freed correctly, all edge cases are handled properly and not throwing exceptions, and if the implementation internally as expected.

Perform a regression testing means that a developer or QA team has to perform automated or manual regression testing to see if a new feature breaks nothing in the whole project.

The main problems of Validate implementation are manual testing and knowledge sharing. Bare implementation contains functionality, but missed knowledge what the implementation can do and how, what are the limitations. It is good if implementation and modification of a feature is done by the same developers, that know how feature works internally. Probably there is no need to express how difficult to different developers to validate the feature change — to understand how a feature was working, if the feature works now without having knowledge just looking at the code is a really complicated task.

A project has tests

Validate the implementation here usually means that a developer runs unit and integration tests to validate the implementation and see if there is no a side effect. The tests here, newly added and existing, will show immediately if something is wrong on any level of the whole project.Failed tests cases should be reviewed and a developer has to understand why the tests are broken and make them working again or modify failed test-cases if a new feature changes business logic. During writing a test-case for an implementation a developer usually puts in a test-cases knowledge how a feature should work: what is a “happy path”, what are edge cases, what happens if incorrect input is passed in and so on.

The main idea in such implementation is start implementation with writing a test and putting knowledge of implementation inside the test-case and implement a new feature iteratively, step by step. That is distinctive feature of Test-driven development approach comparing with just writing a unit test for some implementation.

Perform a regression testing means that all test-cases are run and there is no failed tests, and it is done by a developer. This will ensure that a project will work predictably and no misbehavior will appear. If a QA team presented here than QA team will also run some automated functional and integration test-cases to ensure that all flows are working fine.

The difference between two approaches

Few important aspects could be highlighted here: perform testing of a feature and knowledge sharing about how a feature works internally. These two aspects are affecting time of implementation, modification, refactoring, and all together cost of whole project. Validation is time-consuming task — then why validation is matter of manual testing? Running automated test-cases is many times cheaper than doing manual testing with possibility of overlooking something important.

Transferring business requirements into a test-case, writing a test and an implementation are one solid action and such approach solves few problems:

shares knowledge of implementation;
shows boundaries of implementation;
simplifies regression testing and eliminates blind changes of a feature;
much harder to add breaking changes unnoticed.

Providing a counter-argument for “Writing tests are taking time, and it is hard to meet deadlines writing them” it would be great to take a look at an image and tell to a counter-party that a project will never meet a deadline some time after start with an approach without reliable and automated testing. Time-consuming is not writing tests, but time-consuming is a validation of even a small change or adding a new feature in a huge project. Without proper testing of project internal implementation it is mostly impossible seeing how a new feature interacts with existing components, how the whole project behaves after the change, and usually after some time it is difficult to manage development of projects without tests.

When writing tests could take much time?

From my personal experience I would notice probably only one reason why writing tests could take a lot of time - it happens only when developers write an implementation first and then try to cover a newly added implementation with tests. The main principle of Test-driven development approach is to implement a feature iteratively: write a test and an expectation where a test fails, write an implementation when a test passes, refactor to approach an implementation to a desired result and then the cycle repeats. A developer approaches final implementation step by step.

If the Test-driven development approach is disrespected then it leads to cumbersome implementation of test-cases just because it is hard to cover an implementation. Usually in Test-drive development a source code is written from a prospective how painlessly test it. So, following Keep It Simple Stupid (KISS) principle, design patterns, and clean code practices facilitates writing fine-grained source code where every component is small and simple enough to have a small and clean test-case.
A test-case is a place where a developer shares knowledge how an implementation works and what limitations an implementation has.

Conclusion

Test-driven development approach usually is part of Agile software development practices, but can be used mostly with any development process. In my opinion, writing high quality software is possible only using Test-driven development approach and developers do not spend sleepless nights fixing urgently defects that affect business. Test-driven development approach itself leads to an exciting world of Agile development in cross-functional teams where each member acts as a software developer, analyst, QA engineer with smooth and transparent work on a project.

DEV Community: Alex Lunkov

Mock server

Storing a Java collection in a file storage

Example

How it works

Create a collection

Add items in a collection

Apply operations on a collection

Customization

Want to try it out?

What is it like to develop applications using Golang when you have experience with Java?

What is it like to develop applications using Golang when you have experience with Java?

Test Driven Development with Golang

Mocking with Golang

Behavior Driven Development with Golang

As a conclusion

Resources

Dependency injection and unit testing

Assign dependencies to class field by DI framework

Assign dependencies to class field via a class constructor by DI framework

Why final matters here?

Conclusion

Sources

Handler - why small implementation is good?

A software application and a handler

How much logic should contain a handler?

Conclusion

How to calculate thread pool size in Java

Compute-intensive tasks (CPU bound)

I/O tasks (I/O Bound)

Conclusion

Test-driven development — I’m feeling lucky

Intro

Typical development process

A project has no tests

A project has tests

The difference between two approaches

When writing tests could take much time?

Conclusion

Why `final` matters here?