Category: Technology

Welcome to the first article from our FutureTalk series. FutureTalk features articles written in cooperation with top experts in the field on a wide range of topics in the area of software development.

In the following article, we focus on the topic of agile development and its future. Together with Tomasz Liberski, Service Delivery Director at Espeo Software, we go through the evolution of agile and we share valuable predictions about its future. Continue reading to learn more.

What is agile? A few words about Agile Manifesto

The Agile methodology was initially outlined for software development. It emerged from the concept of Lean and was defined by seventeen software developers in the Agile Manifesto in 2001. The Manifesto, created as a result of a discussion about the future of software development during a Snowbird summit, is based on twelve principles, which can be found here.

Benefits of an agile development

Some of the advantages of agile approach include:

• Continuous improvement
• Disciplined execution
• Iterative feedback
• Stakeholder involvement
• Increased transparency
• Efficient communication with proactive team engagement

An expert’s view of the fundamentals of agile

The Agile philosophy revolves around the fact that every team member works closely together and the Product Owner bridges the gap between the business world and the technical world. Clients and software houses used to communicate and work together under strict terms in the past as the processes weren’t flexible and the cooperation was constrained with contracts. This started to change after companies started following the agile philosophy. Agile requires a great deal of education on both sides as it consists of a number of decisions which decrease the amount of redundant work that has to be done. With an agile approach, the development team is an integral part of the business – they understand why they are working on something and they have a feeling of a common goal. As a consequence, the team is more engaged and has a bigger impact on the project’s shape and success.

Time and time again companies have trusted us as a software development provider. Read more about some of our projects and find out why.

Agile means that every team member needs to take part in the decision making on a daily basis as well as take the responsibility of it. Moreover, it allows for the free exchange of ideas – every member of a team can contribute ideas and impact the development of a project. Some say that developers are not keen on working in agile. There is the idea of becoming a T-shaped profile (a general experience in all areas) so that everyone can exchange ideas and share their knowledge. Many developers, however, are opposed to this approach and instead prefer to specialize in one particular field.

The evolution of agile

When Espeo was established in 2008, it was among the first software houses to emphasize agile development. At that time, the agile approach was notably preferred both by software houses and the clients – offering agile development was one of the factors taken under consideration before starting a cooperation. Today, however, the phrase “agile” has in some ways lost its value – it is often overused, so people view it with skepticism. Nevertheless, if you consider Agile manifesto as a collection of rules and beliefs rather than a methodology per se, it still forms a valuable core for managing software houses and projects.

With 14 years on the market, we have gained valuable expertise in various areas. Read more about what we excel at.

Over the course of time, we have noticed that companies have departed from the core of the agile manifesto – its principles and beliefs have eroded. Instead, organizations have adopted specific practices that are not indicative of agile but are believed as such (e.g. a daily stand ups). Conventions such as daily stand ups aren’t at the heart of agile – they have not been stated in the Agile Manifesto. They are, however, good practices and are commonly used in many companies. The downside of this is that people have come to associate agile with such practices, and the agile values have lost their importance. The foundation of agile development consists of a variety of values. Agile practices are a totally different thing – they address the same values but are different for every organization. Companies that implement agile values can freely adjust their practices according to the inspect and adapt rule and e.g. have a sit down and not a stand up.

Contact us

It has been argued that agile values are outdated, although I believe that the original agile principles included in the manifesto are still relevant and adequate. This doesn’t mean that certain agile principles haven’t been tested over time. For instance, in the pandemic times, the rule about face-to-face communication may no longer hold much significance. Moreover, it is arguable if the communication using different online platforms is less effective than face-to-face communication. In an international setting, for instance, online communication makes it easier to communicate regularly between technical and business professionals on a daily basis. Martin Fowler has once written that most groups are more productive working in a co-located manner. I believe that a well-assembled team that works remotely can outperform a co-located team composed of inaccurately chosen members. The same applies to teams with members located in different time zones. If synchronous communication is maintained, the project has high chances of succeeding. It is the asynchronous communication that slows down the processes in complex teams.

What the future holds for agile development? Tomasz Liberski shares his predictions

There are a couple of predictions for the future when it comes to agile. Firstly, a certain power struggle can be observed. Employees demonstrate that remote work can be just as effective as working on-site. On the other hand, many companies indicate that on-site work is better. It is therefore likely that agile principles will continue to adapt to the remote reality of managing projects. Secondly, globalization will continue to have an impact on software development processes. This means that agile principles will play a big role in the management of software projects across borders and the implementation of global strategic management processes of many companies across the world. In terms of agile (putting remoteness aside), there are voices arguing that it is the right approach at early stages of product development (e.g. MVP). Nevertheless, to ensure the success of the product later in the lifecycle, a focus on high-quality processes and continuity is crucial. This is where the topic of DevOps comes in. It can be viewed both as an evolution of agile and its complement. The last prediction for the future of agile is that the term itself will undergo a certain type of rebranding. As mentioned earlier, this term has become a buzzword in a way. In order to promote its beneficial values, it might get modified to better suit the current industry climate. What is for sure is that agile is a useful and still timely philosophy, and its rules (when correctly applied) benefit the organizations.

Ready to build a successful digital product together? Leave us a message and we will get back to you shortly.

In the previous article, I explained the difference between types of tests for front end applications and answered the question of which tests are required for different types of projects. In this article, I will recommend the best modern frameworks and tools to handle front end application testing for React. I will also highlight common testing mistakes that one should avoid.

Unit tests

There are three main frameworks for doing unit tests for JavaScript applications: Mocha, Jasmine and Jest. Mocha is very flexible but always requires importing other libraries in order ro be able to write tests. Tools like the Chai assertion library are needed etc. With Mocha, you can create your unique testing setup with a lot of flexibility. Jasmine has existed in industry for years. It is a mature testing framework and currently works with test runner Karma default testing framework for Angular. Karma always comes with a difficult config that you might not want to play with. Finally, we have Jest which is a very popular testing framework, recommended by Facebook with dozens of tutorials and examples on the internet.

All three frameworks will do the job, and with the help of other libraries will make testing React applications efficient. My recommendation is Jest because of its simplicity, no need to add separate assertion libraries or create expensive configs. Tests are executed very fast, which is important for large projects with high coverage.

Jest provides very useful options for mocking. You can mock whole modules for your application using manual mocks, you can mock any es6 module for specific tests only using class mocking or simply just mock particular functions. From my experience, mocking is something used very often to make our tests closed in a bubble, separated from external dependencies. That mechanism needs to be easy to use and cover all possible mocking scenarios, and that’s what Jest provides. The list of predefined assertion/matchers is also huge, with no need to extend it.

My recommendation: Jest

Component unit tests/Integration tests

Jest is a perfect choice for standard unit tests of pure functions. However, when it comes to the component or integration testing, Jest starts to not be enough. By default, Jest and React come with a react-test-renderer package which can transform components into JSON objects. This mechanism is used for snapshot testing.Jest is a perfect choice for standard unit tests of pure functions. However, when it comes to the component or integration testing, Jest starts to not be enough. By default, Jest and React come with a react-test-renderer package which can transform components into JSON objects. This mechanism is used for snapshot testing.

Snapshot testing is used for making a DOM nodes JSON representation of a component and storing it next to the component file. We can compare a previously taken snapshot with a new one the next time tests are run. If there is a difference, tests will fail. Snapshot testing in most of the cases is a waste of time. It can only catch changes to the DOM structure, so if you make changes to components, you’ll need to update our snapshots. It can be only useful when you are 100% sure that component is working and want to prevent someone from changing it. Any changes will cause your test check to fail.

A much better idea is to simulate DOM rendering outside the browser. You are able to render components and see a rendered DOM structure in the console. You can also simulate user events on specific DOM elements and observe how your components are changing. There are 2 popular solutions you can use: Enzyme or Testing Library.

Enzyme

Enzyme library was designed only for React, it comes with 2 ways of testing: shallow rendering – which is helpful to test components as a unit without child components. If your components have very high granulation with nested child and grandchild components, it will mean that each of the children will need to have its own specific test to cover whole logic. It is not a very efficient approach. Full DOM rendering in Enzyme is rendering virtually the whole component tree. You can interact with components simulating user events. You can use assertions anytime to check if parts of a component are rendered correctly after each interaction.

Testing library

Testing library was designed for all major SPA frameworks. There are versions for Angular, Vue, Svelte, React and other less popular ones. Testing library is doing full DOM rendering with a large set of helper functions to query and find specific nodes.

Full DOM rendering without a browser is possible with both Enzyme and React Testing Library but writing tests in React Testing Library is a much better experience than writing tests in Enzyme. The querying of data is easy. Firing events are very intuitive. Testing Library focuses more on having as close user experience to E2E testing experience as possible.

With React testing Library you are writing tests imitating user interactions in real browsers. Usually, each test will be constructed in similar way:

• Rendering a component, group of components or page, each Single Page Application framework has its own rendering methods (for React).
• Querying needed elements to make interactions. It’s always good to make separate data-testId attributes for all elements used by tests. Searching over the project, you can easily find all elements which are used by your tests. This way you are not using class/ids which are used for styling and may change because of some styling update.
• Firing events on previously queried elements like button clicks, or filling inputs/textreas etc.
• Query elements you want to check and use js-dom helper library to create proper test assertions. Usually, you check if some element exists in DOM as we want to test from the user’s perspective. This way you can see if the changes are seen by the user as expected.

My recommendation: React Testing Library

Check out also: What front end tests you should write for your next project in 2022

E2E

There are 2 different types of E2E frameworks: Selenium and non-Selenium ones. Selenium tests use a webdriver to interact with browsers. Non-Selenium frameworks interact with a browser directly. Years ago Selenium frameworks were ruling the E2E testing world but recently we can observe that non-Selenium ones are getting more and more popular.

In the Selenium based approach we are able to use interfaces for all popular programming languages like: Java, Python, Ruby or Javascript. I had the opportunity to be part of an existing project with Selenium Python based tests. Creating those tests was painful and time-consuming. Let’s be honest, the browser world is a Javascript world and having an e2e test consistent with language used for creating web applications is a game changer. Having a Javascript application running on a browser and interacting with it using Selenium interface in Ruby, Python or any other non-javascript language is making stuff more complicated and in my opinion the decision to choose such language is always pushed by developers who are comfortable with a specific language.

There are a lot of different comparisons between selenium and non-selenium solutions. The main disadvantage of using non-selenium solutions is missing the functionalities like supporting multiple browser tabs which cannot be achieved without a webdriver. E2E tests should always focus on application functionality and follow paths users follow. Tests which require switching between tabs and leaving one application context should be avoided, and if needed covered manually to reduce further tests possible instability.

I suggest using one of the frameworks which interact directly with a browser because of the setup simplicity, low entry level, and a way of writing tests which feels like standard Javascript development and produces much less code than Selenium solutions.

The most popular frameworks which interacts directly with a browser are:

• Cypress
• TestCafe

Both frameworks provide similar capabilities. The choice is difficult. In past projects both did their job without any problems but when starting a new project I’d go with Cypress because of its popularity among the community. Community support is a huge thing, it means that if any problem appears, you will always find a proper solution which someone has already faced before and solved.

Cypress works fully asynchronously. Before running it, you need to decide which browser the tests should run on (the browser needs to be installed on your computer or Docker container used by pipeline), on what resolution etc. Typical test consist of:

• Visiting specific page url you want to test
• Query and Interact with elements on page
• Query element on page you want to check and use one of provided assertion methods to check if you get what we expected

Our recommendation: Any non-selenium One (preferred Cypress because of the community support)

Front end testing frameworks: common problems

So you have decided what tests you need to write for your project based on the client requirements. Next, you need to pick up the recommended frameworks for doing the job. You are ready to start writing your tests…but you need to be very careful. Tests can make your life easier but when the project is growing and growing, you can end with a bunch of possible problems and big headaches.

• Flaky E2E tests – term is used when you have tests which sometimes pass and sometimes fail. Making your pipeline unpredictable. Test flakiness is caused by small mistakes you have made in the test codebase. Main reason may be the test dependencies, not waiting till asynchronous action will finish or inconsistent initial state of application. Applications empty or full of data may need a different testing approach for some features like long lists with paginations.
  
• Sleep function – using sleep function is a bad practice. Sometimes when you write tests, you may put sleep time to wait a specific amount of seconds and then check if the assertion is correct. You should never do that and use alternative methods of waiting if possible. Sleeps are making your tests run longer and slowing down whole pipeline execution.
  
• Huge E2E execution time – E2E tests are time expensive as each time test needs to open the browser and execute necessary initial user actions like login and accessing specific routes. Covering all possible user journeys with E2E tests will make your pipeline very heavy. Because E2E is expensive, you should cover only the most important paths with it. Some features may be covered just by units or integration tests which will run much faster.
  
• Time-consuming mocking – some components rely on multiple data sources from outside like redux store, i18n providers, graphQl wrappers or context API. To be able to achieve full DOM rendering and test components effectively, you will need to mock all the things to be able to render components correctly. Also, the child components may have their own data requirements which are not passed as props from the parent. Creating a test for such a situation may be difficult and time-consuming. Hence it is much easier to cover such a component with an E2E test which doesn’t care about component implementation details. Alternatively, you can consider some refactoring to be able to test the functionality with a set of small units.
  
• Snapshot testing – snapshot tests are not giving you any useful information except the fact that you know that component DOM has changed. Instead of doing snapshot tests, you should invest time doing other types of tests.
  
• Running always all tests – running all possible tests for all branches will make your CI tool always busy. Especially for larger projects, when execution of all tests may take around 3 hours. Better to execute different tests on different branches. It’s perfectly fine to execute only units on feature branches and check some most important E2E on the develop branch and run a full set of tests just on staging.

Summary

Testing solutions are evolving very fast. New frameworks come and go. Because of this, it is hard to be up to speed on what tools and frameworks should be used. I hope you are no longer confused about what should be part of your new project development setup. Picking up: Jest, React Testing Library and Cypress is a safe choice for your new project in 2022.

Have you ever wondered what a programmer does on a daily basis? In the following article, we will dispel all your doubts! We invited Michał, Wojtek and Bartek, three of our Node.js developers, to share insights into their everyday professional life and the projects they are working on.

• What projects are our Node.js developers involved in?
• Does every programmer’s day look the same?
• Do they spend their entire day writing code?
• What learning sources do they recommend to other Node.js developers and where do they gain their knowledge from?

You will find all the answers to these and more questions in the text below.

What projects are our Node.js developers working on?

Michał Starski (Regular Node.js developer): is working on a platform for bank employees to manage electronic assets (mainly cryptocurrencies).

Bartek Wieczorkowski (Senior Node.js developer) is working on a platform for process management and online medical services. This application allows patients to log into the system as a public service paid for by the local governments of individual cities. Thanks to this, patients can easily register for appointments and tests to selected specialists and easily check available medical services.

Wojtek (Senior Node.js Developer) works on a project in which he creates a platform for integration with financial institutions.

Do you want to work on unique projects that change the world of technology?
Join us!

What are the constant work elements of their day-to-day job?

• Daily // stand-up meeting: a team summary of yesterday’s work and discussion of the plan for today. It is an important element of everyday work, in which the team members and the customer (Product Owner) participate. Thanks to the daily meetings, you can check if the scheduled tasks have been successfully completed and if any problems occurred as well as update your action plan for the day. It is also an important moment for the Product Owner who keeps track of the project status.
  
  
• Programming: after the daily meeting, it is the time for the most important thing in the developer’s work – programming. Usually, our employees have a great freedom and flexibility in projects, thanks to which they can plan the time and sequence of tasks themselves. In the course of work, they also implement tickets in Jira and fix functionalities. Consultations with team members and helping others are also an integral part of the work. Due to the fact that node.js is mainly a backend, a large part of a node.js developer’s work is consulting with the frontend developer and checking his or her needs in relation to the backend. After all, teamwork is at the heart of programming.

Most of our developers work in scrum in usually two week long sprints, i.e. periods of time for which short-term project goals are set. The elements of one sprint are:

• Backlog refinement
  
  Backlog refinement is the work on the Product Backlog during which the tags that can be used in the future are estimated. As a result, the Backlog with each iteration contains better prepared elements that are decomposed and estimated with identified dependencies, and also understood together at the appropriate level. During the backlog refinement, “planning poker” usually takes place, during which each team member estimates one task in the best way according to him, and then the whole team discusses its legitimacy and jointly sets the estimation. Backlog refinement provides expanded knowledge of what awaits the development team from the perspective of the entire backlog. Thanks to this, the team knows what and why they will be doing, and is also able to identify various dependencies in advance.
  
  
• Sprint review
  
  It always occurs at the end of a sprint. It takes place in various ways. Usually all the successes and elements to be changed in the field of work on the project are listed on the board, and ideas for implementation are discussed. Then, there is a discussion on each of the listed topics. An important element of the sprint review is “shout out”, i.e. clear appreciation of successes. It is a form of appreciation for developers that receives special attention.
  
  
• Sprint planning
  
  Sprint planning always takes place after the sprint review, on the basis of which the client evaluates the previous sprint, estimates how much the team is able to do and on this basis fills the task table so that the estimation covers the sprint period.

Some of the developers, who do not work in the sprint system, work according to extreme programming techniques, i.e. by working closely with the client and providing solutions depending on current needs. In this system, much attention is paid to testing and planning with the customer. What does work in this system look like? We asked Wojtek, whose project is based on extreme programming assumptions:

“We have single components that we can test directly without using a dozen services, we also have a lot of autonomy. We can afford to separate the complexity. In our work, we focus on: test driven development, simple design, hexagonal architecture as well as microservices. According to the rules of extreme programming, we focus a lot on quality, tests and programming in pairs. Direct cooperation with the client makes it possible for us to sit down together and edit the code at the same time. “

Additionally, our developers have meetings with Project Managers once a month. This is the moment to check how they feel about their project and if there is anything they would like to change in the context of their work. In addition, they also hold regular 1-2-1 meetings with Team Leaders, where development and evaluation opportunities are mainly discussed.

Is development and setting your career path important to you? Join our team!

Due to the experience and seniority of our Senior Developers, apart from the daily programming part, they are also responsible for architectural issues. These include the selection of tools, patterns, application implementation issues – so the entire product lifecycle. Our developers, apart from their excellent technical skills, are also technical consultants for clients. Thanks to this they are an integral business part of every project.

An important part of the day is also the time for self-development. At Espeo, we set the bar high and help our employees grow. This is possible thanks to, among other things, an individual training budget allocated to each of them. They are supported in this by Team Leaders, who determine the best development path and ways of its implementation.

In addition, our developers often use different sources of knowledge themselves. What do Michał, Bartek and Wojtek recommend for beginner and advanced Node.js developers?

• Michał: “Nowadays, YouTube is a good source for me to develop specific skills. I find a lot of valuable content there with which I can improve my skills or find answers to current problems. In addition, I often check the Massachusetts Institute of Technology (MIT) courses where I am currently expanding my blockchain knowledge. If someone needs more structured knowledge, I recommend the Udemy platform, mainly when it comes to frontend development.”
  
  
• Bartek: “As for the courses for beginners, I can recommend the ones on Linkedin Learning platform. You can find a lot of interesting content and build a solid foundation.”
  
  
• Wojtek: “First of all, I would pay attention to getting to know the concepts, because language is an utility to achieve certain goals. Thanks to the Node.js’ speed you can apply design patterns at a high scale. In this context, I recommend the literature that is the basis for my work. This includes: Pragmatic Programmer by Andy Hunt & Dave Thomas, Implementing DDD byVaughn Vernon, Patterns of Enterprise Application Architecture by Martin Fowler.”

Node.js is an increasingly popular programming language that allows you to work on unique, unconventional projects. Thanks to our developers’ solutions, we are able to collectively change the world of technology and develop various problematic areas. At Espeo, you have the opportunity not only to work on exceptional projects, but also for continuous development, support of a team leader in determining and implementing a career path, as well as work in an ambitious, expert team. Sounds good enough?

Ready to have a real impact on the projects you are working on? Apply to one of the open job positions now.

The thesis might seem controversial in 2021 when in many rankings such as TIOBE, Java seems to be slowly overtaken by languages such as Python. However, despite the changes due to growth of areas in IT in which Java has never dominated (for example data analysis), there is no premise that in systems where this language is most popular it will be displaced. Listed below are some reasons why, in my opinion, Java still holds such a strong position today.

With 14 years on the market, we have gained valuable expertise in various areas. Read more about what we excel at.

Being the first is why Java remains so strong

In many ways, Java was a precursor of programming based on compiling language into intermediate code. The concept itself wasn’t new, as the first language to use this approach was Smalltalk developed in the 70s, but due to limitations in hardware and the nature of the syntax, it didn’t gain as much popularity.

The fact is that when Java was released, it had few elements that were revolutionary, but the key to its success was combining those elements in the right way and learning from predecessors’ strengths and weaknesses. Microsoft later used this approach in developing C# by utilizing Java’s experience.

On one hand, the syntax based strongly on C++ which was the most popular language in the general-purpose category at the time, made the migration very easy for its users. Also it simplified many elements such as memory management via garbage collector or optimizations via Just in Time compiler. In addition, it gave a set of predefined tools and components in JDK.

This attracted many users at Java’s launch and boosted the start of this technology. Even now, the number of programmers skilled in this language is a common reason for choosing it for a project from a business perspective.

Check out also: What front-end tests you should write for your next project in 2022

Backward compatibility as one of the strengths of Java

This is a big advantage, especially for systems with long-term support. Thanks to this policy, the language avoided perturbations known to programmers for example from Python 2 to 3 migration.

An approach like that doesn’t just affect syntax, it is even more explicit on the virtual machine level, as evidenced by the fact that from the beginning of existence to the Java 8 release, only 2 instructions were added to the bytecode on the virtual machine. This of course doesn’t make migrations between versions costless but it certainly reduces their complexity.

Such an conservative approach creates yet another non-obvious advantage. Java is not a syntax sugar laden language, which on one hand makes many things impossible to do in a very short way. On the other hand though, this verbose approach in many cases makes code refactoring easier, without a very high level of necessary knowledge.

In other words, badly written code is easier to read and fix in Java than in more complex languages.

Time and time again companies have trusted us as a software development provider. Read more about some of our projects and find out why.

Java can be easily integrated with a variety of tools and libraries

Here comes probably the biggest advantage of the discussed language – its age. Because of it, Java encourages maturity of solutions and has a large community. It’s hard to find technologies without prepared integration with Java or functions that aren’t provided by external libraries.

An important attribute of Java is that although the syntax evolves slowly, progress of tools is fast enough to never deviate from current trends.

A good example of this is the transformation that the Java systems underwent through the creation of the Spring framework. It greatly improved the development of enterprise systems, especially in relation to Java EE. Huge evolution was also made in other areas as well, such as tools for managing dependencies and building. The Java community has gone from requiring complete manual configuration Ant to much more convenient and automated solutions like Maven and Gradle. In other words, it is an ecosystem that is alive and evolving.

Another important feature is the independence of choosing languages compatible with Java as it allows one to benefit from the toolset without using Java syntax. Apart from Java itself, alternatives include the increasingly popular Kotlin, dynamically typed Groovy or more functional and competing mainly in the big data area Scala. There is no shortage of opinions that Java may at some point move into the role of “assembler for the JVM,” giving way to current alternatives within the same technology stack.

Want to estimate a Java project? Don’t hesitate to contact us.

Summary

After 26 years of existence, the position of Java on the market seems to be unthreatened. The technology stack based on it constantly adapts to new trends, allowing to start new projects based on it without lagging behind solutions offered by the competition. It is still attractive enough to be the first chosen language for many programmers.