The dynamic growth of Espeo Software has inspired us to introduce a new role of a Delivery Manager, which has appeared in our team at the beginning of 2022.
The Delivery Manager role will bring more transparency and easier communication (ownership on the project) in our project management and will provide our clients with even better possibilities to achieve their business goals.
The development of our organizational structure reflects our strong focus on our clients and the changing role characteristics on the market. Moreover, our organization allows us to offer the best services to you as our partner as well as create an inspiring working environment for our Crew.
We are proud to grow and to develop. Later this quarter, we will share with you more details about the Delivery Manager role and the opportunities it offers for your development project.
Interested in joining our team as a Delivery Manager? Check out the job offer and apply!
We are coming back with another article from the Business Value Assessment series written by our Senior Digitalization Consultant, Kris Honkola. Kris is a business and solution consultant at Espeo Software, in addition to also working as a Project Manager for our Finnish customers. He specializes in solution consulting, business analysis, and digitalization brainstorming, focusing on the business impact of digital solutions. Kris has more than 30 years of experience in the IT industry, significant hands-on knowledge of developing commercial systems and managing the entire lifecycle process of IT product development.
In this article, Kris discusses the benefits of Business Value Assessment which are sometimes overlooked while considering digitalization:
justifying an investment in digitalization with business reasons
creating a professional and accurate investment presentation
coaching the technical leadership in order to deliver the presentation well
How to justify an investment in digital transformation
The key benefit of a Business Value Assessment (BVA) is the financial justification of investment in digitalization. BVA supports the financial justification with ROI, calculations as well as in-depth explanations of the investment benefits. However, there are many other benefits that companies can derive from working with Espeo Software during Business Value Assessment workshops. Let us look at a few examples.
A business story explaining the benefits of the investment
Having an excellent ROI calculation does not always mean that funding will be forthcoming. Therefore, the justification of the investment needs to be a part of a story that supports the goals of the organization. Let’s consider a scenario where the main goal of the organization at the time is to improve customer satisfaction visiting their web portal. To demonstrate that the investment will improve customer satisfaction, the investment story needs to demonstrate concrete examples of how the investment will benefit the organization. This is something that IT directors and CIOs often do not include in their funding requests. In my role as an external consultant, I can help develop a financial impact story that supports the funding request.
Providing professional presentation that supports the objectives of the investment
In my 30 years of experience, I have seen quite a few funding requests for various IT and digitalization projects. Usually, they include a technical document explaining the technologies to be used, along with a brief description of the potential benefits. In most organizations, these are targeted at financial leadership, such as the CFO. Sometimes they may even target the board of directors. These people, however, usually have a substantial background in finance and often do not fully understand the technical document of this kind. Moreover, are they really interested in the content of the document? To justify their investment, they need a well-calculated return on investment (ROI), as well as the understanding of what the potential business benefits are.
Coaching the technical leadership to deliver the findings well
When we at Espeo Software finalize the BVA report, we often present the results to the CFO of the company. However, this is not always the case. Many companies do not allow external consultants to report directly to the Board or the CFO. On those occasions, the person who will report the results needs to be coached in order to deliver the findings correctly: using the business story and the right materials. Nevertheless, it is not enough to have the right story and materials. One has to be careful how the information is delivered. Despite their desire to cut costs, CFOs are eager to see what kind of return an investment may produce. Because of this, it is important to communicate that a particular digitalization project has no costs, but that it is an investment opportunity that supports the company’s goals.
Interested in learning more about Business Value Assessment?
Don’t miss out on our expert’s insights and make sure to check out all articles from the series:
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.
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:
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:
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?
We use cookies to optimize our website and our service.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
We use technologies like cookies to store and/or access device information. We do this to improve browsing experience and to show personalized ads. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
