www.codenewbie.org Open in urlscan Pro
52.20.78.240  Public Scan

Form analysis
0 forms found in the DOM

Text Content

 * 

Home
Podcast
Codeland
Base.cs
Blog
Chat
DEV
Forem


SEASON 18 EP 4 NOVEMBER 29, 2021


HOW TO MAKE SENSE OF THE TESTING LANDSCAPE SERGEI EGOROV

Play
Current Time 0:00
/
Duration Time 0:00
Remaining Time -0:00
Stream Type LIVE
Loaded: 0%
Progress: 0%
00:00
Fullscreen
00:00
Mute
Playback Rate
1x
 * 2x
 * 1.75x
 * 1.5x
 * 1.25x
 * 1x
 * 0.5x

Subtitles
 * subtitles off

Captions
 * captions off

Chapters
 * Chapters


Play
Current Time 0:00
/
Duration Time 0:00
Remaining Time -0:00
Stream Type LIVE
Loaded: 0%
Progress: 0%
00:00
Fullscreen
00:00
Mute
Playback Rate
1x
 * 2x
 * 1.75x
 * 1.5x
 * 1.25x
 * 1x
 * 0.5x

Subtitles
 * subtitles off

Captions
 * captions off

Chapters
 * Chapters



Don't let testing test your patience

Download

Subscribe

Tweet

Sergei Egorov

CEO AtomicJar

@bsideup

Sergei Egorov is CEO at AtomicJar, co-maintainer of Testcontainers, a Java
Champion, Reactive Foundation TOC Member, Apache Software Foundation committer,
contributor to a variety of open source projects, and former staff engineer at
Pivotal (acquired by VMware).

DESCRIPTION

In this episode, we talk about how to make sense of the testing landscape with
Sergei Egorov, Java Champion and co-founder and CEO of AtomicJar. Sergei talks
about how he got into testing through game development, the different major
types of testing, and some classic types of failures that are revealed by each
type.

SHOW NOTES

 * AtomicJar
 * JavaScript Injection
 * Testcontainers
 * Manual testing
 * Automated testing
 * Unit testing
 * REST API
 * GraphQL
 * End To End Testing
 * Integration testing
 * Property testing
 * Martin Fowler
 * Thoughtworks
 * Docker
 * GitHu
 * Pascal

TRANSCRIPT

[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on
their coding journey in hopes of helping you on yours. I’m your host, Saron. And
today, we’re talking about how to make sense of the testing landscape with
Sergei Egorov, Java Champion and Co-founder and CEO of AtomicJar.

[00:00:22] SE: When you see a lot of test failures, one of the first things that
you should check is whether the failures were caused by your test setup or by
the implementation.

[00:00:33] SY: In this episode, Sergei talks about how he got into testing
through game development, the different major types of testing, and some classic
types of failures that are revealed by each type after this.

[MUSIC BREAK]

[00:00:55] SY: Thanks so much for being here.

[00:00:56] SE: I’m so excited to be here, Saron.

[00:00:59] SY: So tell us about how you got started. Where did this journey
begin for you?

[00:01:02] SE: This journey began for me in Siberia, in the cold part of
Siberia, and we aren’t very active outside, but rather inside, and that was the
case for me. I was locked inside. You spent lots of time with your computer, and
that’s how I got into programming. I was just clicking through some random
files, some Visual Basic Script files in System32 folder. And apparently, I
realized that some of them I can change, and that’s how it all started for me.

[00:01:30] SY: So you were playing around, kind of messing around with stuff.
What was your reaction to that? Why were you messing around and what did you
take from that experience?

[00:01:39] SE: First of all, to answer your question why, because I got bored
with games. I run out of games on my CDs. Yeah, I didn’t know what to do. So I
was like, “Okay, what else can I do with this powerful machine in front of me?”
People talk about computers and computers can solve big challenges, big problems
in the world. But apparently, I had no idea how they work and what they do. So
that was my why, it’s why I started taking these files without having any clue
what they’re doing. And just something clicked in my head that, “Hey, when you
change them, you modify the behavior.” And it was my very first interaction with
the concept of programming. Apparently, it can edit some files, it can edit some
texts, but then it will result in some behavior being changed.

[00:02:24] SY: So how did that first exploration, that curiosity, how did that
get you to where you are today?

[00:02:30] SE: I actually relatively quickly transitioned from trying to
understand programming into trying to do some hacking because of movies and
other things and I grew up in the ’90s, I’ve been watching some of these hacker
movies. So I was like, “Okay, I want to become the world famous hacker.” And I
started learning how hacking works, like how people break into systems. And
while I wasn’t breaking into any systems, I didn’t want to cause any harm, but I
just wanted to understand how it works, like how people do that, ended up being
sort of a white hat hacker. I mean, a beginner won’t be someone who would break
into Pentagon or something like that, but discovering some JavaScript injections
and SQL injections and stuff like that, something that I was enjoying doing and
then reporting back. But at some stage, I realized that, “Okay, I need to
understand the systems behind what I’m trying to break into so that I can do it
better.” And it became so exciting that I was like, “Okay, I don’t care about
hacking anymore. I just want to build the systems. I don’t want to break them.”

[00:03:39] SY: Interesting. Okay. And how old were you? What age are we talking
about here?

[00:03:43] SE: Thirteen, fourteen years old.

[00:03:45] SY: Oh, pretty young. So let’s fast forward from that to the first
job. How did you get that?

[00:03:50] SE: Relatively soon after, I started learning the programming, since
I was still connected to the gaming industry and still playing some games. I
realized that, “Okay, for some of the games I’m playing, I could do something
and apply my programming skills.” And I started writing both for one of the
online games that was very popular in Russia and eventually one of the online
clans and it’s a bit specific to online games, but still they reached out to me
and asked me whether I could create a bot for them that would sell their in-game
currency to their users. And that was my very first job in IT. I just got paid
for creating a bot for a game, online game, and it was fun because I did not
expect to be paid. I was just enjoying what I'm doing.

[00:04:34] SY: Tell me about your learning process. How did you level up? You
started just from kind of poking around and looking around. When it came time to
teaching yourself for a formal job for the thing you actually got paid to do,
what was your process for learning and leveling up?

[00:04:49] SE: So when it comes to learning, the biggest principle I’m using is
this cannot be like that. So sometimes when I struggle with something, I always
change it and think like, “Okay, there is no way someone has never solved it
already,” because that’s the reality we are living in. The IT industry, it’s so
wide, it’s so mature now that we have so many solutions to almost every problem
we’re experiencing. And what I learned that works the best for me is to first
check how the problem I’m trying to solve was previously approached by someone
else already. And most of the times, you will either find an answer or someone’s
resolved that resulted in nothing but at least you can follow the process and
shortcut and save some time, not wasting this time yourself, but learning from
other’s experience. But this was very helpful. And in many things I’m doing
today and many things have been doing in the past, but also what I’m doing today
also as part of our company challenging the status quo is always helpful when it
comes to learning. The second part, like how I earned the knowledge, this one is
interesting because while I did start by learning books, nowadays I’m not really
reading books because the domain I need to research almost all the times
develops much faster than the books get written.

[00:06:11] SY: Yeah.

[00:06:12] SE: You resort in reading either some basics that would apply no
matter when the book is written like 40 years ago or today, but some modern
stuff. Like if, for example, I want to read about, I know something really
fancy, off the top of my head, like something about Kubernetes and something new
they just released, obviously I will be struggling finding a book. But reading
social networks, especially Twitter, is surprisingly a great way to discover
knowledge about things. Who would think that microblogging platform would help
with that?

[00:06:46] SY: So take us to AtomicJar, which is where you are today. You are
the co-founder, the CEO. What is AtomicJar and how did you get started?

[00:06:55] SE: So AtomicJar is a result of us spending five years working
together. By us, I mean, Richard North, original creator of Testcontainers,
Kevin Wittek who joined us later as a maintainer and myself, and also our wide
community of Testcontainers’ contributors and users. But we’ve been working
together on this open source library for five years and Testcontainers has
become something incredibly popular being used by the biggest companies out
there. But we never thought about monetizing it. We never thought about taking
commercial. We had our day jobs, we were paid well, and we never had the problem
with that. But at some moment, we realized that we’re enjoying it so much that
we would like to turn it into something full time. We would like to be spending
our time working with this library because that’s what gets us excited the most.
And although we never had a chance to work with each other at a company, we were
always employed by different companies, additional motivation for us to start a
company was to be finally able to work together, and I’m very excited about it
because this moment when you turn from, okay, just a bunch of fellow open source
developers doing something on their spare time and trading their family time in
favor of contributing a new feature to an open source project that is being used
by the largest enterprises in the world into something that eventually will pay
off and into some things that will let you stay with your family while also
being happy about the progress you’re making with the open source library.

[00:08:33] SY: What has been your experience being not just a developer working
actively on the product, but also just being a CEO and having to run the
business? What has that experience been like for you?

[00:08:44] SE: It’s a very interesting experience. I’m a developer. I’ve been a
developer my whole life, and now I have a lot of things to learn. The good
things at the same approach works like would be wrong to start doing things
without learning from others. And that’s what I’m actively doing in my role. And
this is why it was so critical for us to find the right investors and advisors,
by the way, because these are the ones we’ll be learning from the most, and they
really help. But it is interesting because at least being CEO of a dev tools
company is obviously not the same as being a CEO for social network, let’s say,
or something else.

[00:09:22] SY: Right. Right. Your users are a little bit more demanding, I
assume.

[00:09:25] SE: Demanding, but also you understand them much better. You
understand them because they’re also developers.

[00:09:30] SY: Okay. Yeah. Yeah.

[00:09:32] SE: You can shortcut so many conversations and you can shortcut so
many decisions because, well, I know what they want because that’s what I would
want to have. And that was major contributor to the success of our library,
containers, but also what we do in our company right now kind of reflects the
same ideas that understanding your target audience and your users is crucial to
the success of your startup and our advantage that we are a dev tools startup
and this is why being a developer, CEO means that you can actually be successful
because, yes, you need to learn some other things, like how to operate the
company, especially finance is part of this thing. There’s so much to learn. But
on the other side, at least I don’t need to spend time learning how to
understand our users. We came to a conclusion to start the company because we
already understood our users and we knew what they wanted.

[00:10:29] SY: That’s a great point. So now I want to get into understanding the
testing landscape a little bit more. I know this is your sweet spot. This is
what you guys are all about. Let’s start with the very basics. What is testing
and where does it fit into the developer ecosystem?

[00:10:47] SE: In our case, our company, we are focusing on automated testing,
but there are various types of testing and clicking through the UI and starting
the application, just doing it manually is also one way of doing the testing.
It’s just manual testing. And the way I tend to think about automated testing is
that developers are lazy. They don’t want to do repetitive actions. And as
anyone lazy, we would rather spend five hours automating something that we can
do in one hour by hand. But it sounds like a joke. But on the other hand, the
positive outcome is that if we automate something, then we can rerun this
optimization. And the beauty of automated testing is that those actions that we
would be doing otherwise, every time we need to verify that our application is
working now can be delegated to the machine, to the computer, that we no longer
need to spend time doing repetitive actions. But instead, we can run the test
and test is literally just a piece of code that would do what otherwise you
would be doing. And if you as a developer, previously if you were running your
application and checking that, “Okay, if I’m designing a calculator and if I
entered 2, then if I pressed plus, and I entered 2, then the result should be 4.
What I described is a test case. And this test case can be done either manually
or by writing some code that would be entering these values. And that’s what we
are focusing on. How developers not spend time doing repetitive actions or what
can we do to make it easier for them to write their tests because we believe
that this is the right thing to do. As developers, we have so little time and so
many things to do and doing repetitive actions isn’t the right investment of
developers’ time.

[00:12:48] SY: So talk to me a little bit more about the benefits of testing. As
a developer, you said, “We don’t have a lot of time. We got lots of stuff going
on. We got lots of bugs and squash. We have features to build, users to respond
to for customer support kind of thing. Why bother with testing at all? Why
should we do it?

[00:13:07] SE: I believe testing is an investment in the future. Today, I may
just confirm that the application is working, and okay, like that’s a short-term
win and we already know that the application’s working. What’s the point? Right?
Why should we invest into testing? But as anything else in the world,
applications are being changed. We always get new requirements. We always
deliver new features. And as part of the process, we should always have the
confidence that, “Okay, what we just changed won’t break the way it worked
before.” And now we are talking about spotting regressions and spotting
regressions isn’t an easy thing to do because it requires some prior knowledge,
it requires writing something proactively instead of just listening to the users
who tell you that, “Okay, something is broken.” And writing tests, and I believe
the biggest value of having a test is to be able to understand the current state
of the application as compared to some previous assumptions that were previously
made and the best way to express assumptions and let them stay is to write a
test case because test case will be the representation of the assumptions and
certain requirements for the software you are working on.

[00:14:27] SY: And when did you first get into testing? When was the moment that
for you, you said, “Man, this is an investment that I need to make and this is
something that I want to work on and take seriously”?

[00:14:37] SE: Quite early, I would say. Maybe 10 years ago. I’ve been working
at the GameDev company. And the thing is when you’re working in GameDev, usually
you have very rich clients. In our case, it was an application in social
network. And eventually, I had to spend like 10 minutes progressing through the
game just to get the support that they wanted to test manually. And let’s say
you need to test something like some edge case. You need to test them when you
reach level 80, which is the biggest level in the game. And it takes like five
years to get to that level. You can do certain actions. You have two options.
You can either shortcut by adding some special codes that would make your
profile look like you’re level 80, but it cannot guarantee that your users will
go through the same process. What else you can do? You can write a test for the
particular part that you want to test without having to do something in the UI.
And it clicked with me, like, “Okay, why should I do some actions in UI if I
need to test our backend? Why can’t I just start our backend and do some tests
in our backend?” It was a moment of realization for me that, apparently, I don’t
even need my whole system to pass what I want to test.

[MUSIC BREAK]

[00:16:11] SY: What are the different types of software testing? You mentioned
automated testing, which is kind of what we’re focusing on, what the focus is of
your company. What are some of the other categories of software testing within
that?

[00:16:23] SE: So I’m not sure whether we can say is that let’s say KELS
testing, performance testing, and others are in the part of automated testing
because I really see it as manual testing versus any other type of testing.
Because any type that is not manual, you can repeat. It means that you can
automate it. It means that it’s automated testing. So I would say two
categories. But then automated testing is a rich category with so many
subcategories. One of the most popular ones is unit testing and that’s where you
start. Let’s say you’re a developer and you need to test the implementation of
the calculator, that functions that performs the calculation. And the function
is so-called pure. Its behavior never changes as long as the inputs are the
same. And it isn’t the case with calculator. No matter what the weather is or no
matter which time of the day it is, you’ll always get the same result if you
enter 2 and 2 and plus. So that’s the case for pure functions. And now we want
to test it. We want to test it 2 plus 2 equals 4. So that’s what we do. We wrote
a test that would call our original function, plus 2, 2 and plus as arguments
and we asserted the result. We just check what this function returns and we
write code to test code. There is an interesting question who would test the
test, but that’s another story.

[00:17:54] SY: Yeah. Right.

[00:17:56] SE: Unfortunately, I would say the only way to test your test is to
do manual testing, also known as code review because someone else will look at
your test and say, “Hey, why are you assuming that 2 plus 2 equals 5?” Why? It
isn’t the case, but of course business requirements help with that. But this is
a very simple way of testing and it’s extremely fast. This is why it’s so
appealing to developers. The downside is that sometimes or most of the times our
applications aren’t as simple as calculator. In fact, most of modern
applications are tiny wrappers around database access to transform. Let’s say
the result of an SQL query into some JSON that they return to the client. Some
REST API or GraphQL maybe. So we could test that piece of code that transforms
this from one source to another work, but then there’ll be a lot of logic behind
the queries we send to databases. And this is why we cannot just unit test
everything. We need to test our application with something real, something that
behaves exactly like it would behave in real environment when we deploy it to
production for our users. And for many years, the default approach was to do
end-to-end testing by let’s say doing browser testing. And in that case, if
you’re lucky enough to have a browser application as part of your product, you
could just open a browser and use something like Selenium to click through the
browser, to click through some buttons and verify what you see on your screen.
That would work for a browser-based application, such as social network,
Facebook, let’s say, but then it won’t be covering everything because if you
think about it, we can only do the actions that are allowed by the UI. We can
never send negative value to the H field because we have input validation. But
what if someone, some hacker and you see how I’m connecting it to my hacking.

[00:20:03] SY: Yeah, bringing it back.

[00:20:06] SE: Yes. So let’s say a hacker sends a negative value to the H field
or even not in negative, but some SQL query to hack the system. Obviously, we
need to test that this works as well. We need to test that our application won’t
break, but we cannot enter these values through the browser. So we need
something in between, not as non-real as unit testing, but also some things that
would let us do things that we cannot do with browser testing. And this is where
developer folks are testing in a form of integration testing arises. That’s
something in between. What if we write a test similar to how we do unit testing,
but we start our application with a real database? And instead of using
so-called mocks or stubs in our code, when we do unit testing, we will actually
be sending queries to real databases. So that now which acts that if someone
enters some malicious value to some field, our application won’t return the
passwords for all our users.

[00:21:11] SY: What are some common things that testing helps catch? Are there
kind of common categories of things that we might miss or issues, bugs that
might surface just from getting in the routine and the habit of testing?

[00:21:26] SE: I would say it helps getting rid of assumptions because we
developers who make lots of assumptions, not because we are doing something bad,
just because the way we think, we think that things will work perfectly fine,
for example. We expect computers to work the way we expect them to work. But in
reality, things may differ and there are so many assumptions when it comes to
using a database. And one could think that, “Okay, I will just send this query
and I must be getting this result.” Right? Because that’s what I learned about
this database from the books. And then apparently, you aren’t using the same
version of the database. It wasn’t the books. And instead, you’re getting some
completely different result because the database has made some changes, some
breaking changes maybe, and you’re no longer getting the same result as you
expected. And by running tests, especially integration test, one can convert
assumptions into real facts about the behavior of their application and then no
longer operate on assumptions but on facts.

[00:22:34] SY: So are there specific types of tests that everyone should
implement based on their features or what are we testing exactly? You mentioned
kind of assumptions. But is it really as we build out different features, we
write the list of assumptions and test based on that? Or what does that process
look like?

[00:22:55] SE: It is one type of test that I recommend everyone doing. it
doesn’t really matter what kind of applications they’re developing or what this
application is back end or front end or what’s not. But if I had to pick one
test that should be in every test code base, then I would say an empty one. And
it may sound surprising, but the point I’m trying to make is that a test that
doesn’t have anybody, like any scenario to check any assertions, just an empty
test, by writing this empty test, you aren’t testing your application. You’re
testing your test setup. You're testing that your application starts and you're
testing that your application is ready to perform assertions. And this is very
underrated type of a test, it’s a tree you’ll want to have. But then Day 2
experience with testing, when you see a lot of test failures, one of the first
things that you should check is whether the failures were caused by your test
setup or by the implementation. And then if you see that that empty test is
failing and obviously it should never fail, right? It doesn’t really matter how
you change your application. An empty test should never fail. And if it fails,
then we have a problem with our test setup. So we don’t need to spend time
picking out what we broke in our application because we are not ready to assert
whether our application is working correctly or not because our test setup isn’t
correct.

[00:24:30] SY: Who should be doing this testing? Do you feel like developers who
are part of the team, who are working on the features, do you think they should
be the ones to work on these tests? Or do you feel like we need a designated
testing team to take this on?

[00:24:46] SE: What we’ve seen is progress as part of the DevOps moment where a
lot of ideas were shifted to the left, where a lot of activities were shifted to
the left is the developers because that’s where it all starts, is developers on
the left side. We noticed that testing rapidly getting moved to the left as
well, because in 2010, it was common to use browser testing and to have a
dedicated team of QA engineers, those who spend their time writing tests and
running this test and not features. And it was fine. It worked for companies and
nobody even thought about it as a problem, as a problem of their process. But
then with the transition to DevOps style way of working on modern applications
where more and more responsibilities are shifted to developers or at least align
it with developers, people start to realize that, “Okay, but why do we have a
dedicated team of QA engineers? Why can’t our developers, those who create the
code, the original code, why can’t they test their code?” And I know that there
are many jokes about the QA mindset. Usually the idea is that QA engineers, they
have a mindset that helps them testing better because there are some jokes like
QA engineer and there’s a bar and then he orders one beer, five beers, 9,999
beers, minus 3 beers and so on and so forth. And while I understand the joke,
it’s important to test all the possible inputs. And when a developer writes a
test, usually you would see like, “Okay, 2 plus 2 equals 4,” instead of testing,
like what if I divide it by zero? What if I multiply it by negative value? What
if something? But on the other hand, when developers started testing their own
code, they realize that they don’t want to spend this what-if, what-if. What
they want to do, they just want to randomize the inputs. They want to use
something like property testing to be able to automatically detect possible
values that would be entered that they don’t need to.

[00:27:00] SY: Tell me more about property testing. What is that?

[00:27:03] SE: So the idea is that you define the subject under the test as
something that takes inputs according to a certain definition, and then the
behavior of the system should be reflected by these inputs, by these properties.
And trying to find a simple explanation because that’s a new concept even to me.

[00:27:26] SY: Yeah. Yeah.

[00:27:26] SE: But I would say in a simple form, when you think about it, you
define your test not as something like 2 plus 2, but something that takes two
numbers and provides a result. And then as soon as you define this as inputs and
outputs, you can run an automated system to provide various types of inputs and
assert the outputs without you having to log specific ones, like let’s say just
2 by 2 or something like this, but rather any number with any other number
should be resulting in this number.

[00:28:05] SY: Yeah.

[00:28:06] SE: I’m not sure if someone from the property testing community will
later blame me for this definition, but what I want to say is that I really
appreciate this approach because I think that’s a great way to improve the
coverage of your test or improves the quality of your test. And that’s what
matters.

[00:28:23] SY: So where’s a good place to start? Because with testing, it can
get really in depth, it can get pretty complicated. It can be very
sophisticated, how far you can go testing. What’s a good place to start? What’s
like the starter kit of testing?

[00:28:37] SE: My biggest suggestion would be to identify what you do to develop
the software. And most probably, it would start with, well, I start my
application and then I query this endpoint and then identify the scenarios and
turns them into code. Just write code for that and it will be failing because
you have nothing to start yet. So we need to figure out how to start your
application. Then you need to figure out how to query some endpoints. But this
will come with time when you’re working on your test. But the good thing is to
not try to write everything at once. Let’s start simple. Start with something
small, something that you’re already doing as a software developer. Just
identify processes that you can automate and automate it with your test because
that’s where the value of testing is, and that’s also how you understand how to
follow the process. And eventually, you will be adding more and more tests just
because you learned this process of automating the testing process, something
that previously you were doing was manual testing. And as I said, we all do
testing. It’s just a question of which one you prefer, manual testing or
automated one.

[00:30:02] SY: Coming up next, Sergei talks about some of his favorite testing
tools and resources after this.

[MUSIC BREAK]

[00:30:19] SY: And what are some good resources to get started, to learn a
little bit more, get more comfortable with the lingo, get more familiar with
some of these concepts before jumping in? What are some good places to dig in a
little bit?

[00:30:31] SE: So what I can say is that Martin Fowler from ThoughtWorks would
be a great source of inspiration about understanding all these various types of
testing, how are they compared to each other, what’s the true definition of
let’s say integration testing, what it means and how it applies. And there is an
enormous amount of knowledge in his blog. And I definitely recommend everyone
who thinks that testing is something they want to either learn about, where they
want to improve their knowledge about testing, my recommendation would be to go
for Martin Fowler’s blog.

[00:31:11] SY: And tell me about Testcontainers project, which is something that
I believe you are a core maintainer of, you and your co-founder built it
together. Tell me more about this project. What is it and how might it help
people with their testing?

[00:31:24] SE: So Testcontainers, that was a project created by Richard North,
my co-founder and our CTO, and start it with a simple idea. He noticed that
while he was working on Deloitte Digital, he noticed that there’s quite some
amount of repetitive actions that are required for the testing setup to be done
among their customers. You start thinking what they can do to automate the test
setup because it has a test but one big challenge of integration testing is how
to start everything, how to configure your environment, how to get to
application under the test running, how to get the system under the test
running. And back then, six years ago, Docker was becoming more and more popular
and also people weren’t ready to run Docker in production yet as compared to
today. More folks started realizing that, “Okay, Docker is actually a great
abstraction for setting up databases, brokers, browsers, and literally anything
else that can run in Docker container.” And you know where we need this the
most? Testing. So that’s what he did. He loves the idea of using Docker for
testing, for setting up your test environment. And fast forward to today, it
changed how we test software really. Because before Docker, before
Testcontainers, it was common to assume that, “Okay, the best we can do is some
unit testing and maybe tiny bit of integration testing, but then it would
require us to install on our databases, on our developer’s machines and CI
environments,” and nobody really wanted to do that. So we knew that this is the
right thing to do, integration testing, but we always had this feeling that,
“Yeah, it’s the right thing to do, but I don’t really want to do it because it
takes a lot of effort and I would rather write yet another feature that may or
may not work, I don’t know because I’m not writing my test.” But with
Testcontainers, it becomes as to you as just making sure that you have Docker
available. You have Docker somewhere and Docker becomes the only requirement for
running integration tests and this dramatically improves the situation because
it is much easier to convince someone to have Docker in their machines as
opposed to all these databases that need to be written on their computers. And
that was six years ago. And slightly less than one year since we started the
project, I was working in ZeroTurnaround, a dev tool company in Estonia. And we
kind of have our own Testcontainers but internally. We had the same idea. What
if we talk to Docker directly from our tests and I keep repeating this story,
but I really like it that it has this amazing feature, like I really like this
feature. It’s one of the underappreciated features of GitHub, is the networking
mechanism where you look at some issue and you see references from some other
issues. And this is how you discover other open source projects. I have so many
open source projects that I’m using daily now that I discovered from GitHub just
by looking at these references from other repos. And I was looking at one of
such issues with Docker and there was a reference to Testcontainers. And I was
like, “Okay, I’m looking for a solution for my Docker-related problem for
testing.” And I see a reference to Testcontainers. It does look like something I
should check and I checked it and I was so happy to discover it as a library
because what it was doing is basically the same as what we created, but we
created internally and test container was an open source project, and I’m a big
fan of open source. So a few days later, we started contributing to
Testcontainers and eventually just migrated fully to Testcontainers and have
been doing more and more contributions. And Richard invited me to join him as a
co-maintainer. And ever since then, we’ve been working together and later Kevin
joined us as well on this beautiful library. And when you think about it never,
ever, ever changed since day one. It was always focused on one simple concept,
how to help developers setting other integration testing environment so that
they can focus on writing tests and code instead of spending their time talking
to sysadmin how they can get Elasticsearch running with their CI environment
because they need it for their tests and it shouldn’t be blocked by some system
requirements or by some ops problems.

[00:36:16] SY: Now at the end of every episode, we ask our guests to fill in the
blanks of some very important questions? Are you ready to fill in the blanks?

[00:36:22] SE: Yeah, I think so.

[00:36:24] SY: Number one, worst advice I’ve ever received is?

[00:36:27] SE: To stay low. It started at school really, and I grew up in Russia
and the Russian teachers sometimes tell you that, “Okay, don’t be the one
everyone is talking about. Just be like anyone else. Just be part of this group
of people. Don’t be an outsider. Don’t be someone people notice.” Because they
always think about it in a bad way that you won’t be the one who will be noticed
for something good, but rather something bad. And the thing that was the bad
advice, and I’m happy that I didn’t listen, I didn’t listen to many advisors
when I was young, but the bad part about this advice is that it stops
creativity. And it makes you start looking for ways how to not be unlike others,
how to not be creative, how to stay low. And this isn’t good because we’re all
creative and we need to unlock our creativity. And that’s what helps us be
successful and progress in our lives.

[00:37:24] SY: Number two, best advice I’ve ever received is?

[00:37:28] SE: The best advice I received, I received from my parents, challenge
everything around you, and this is related to my learning process as well. I
mentioned that I challenged current status. I challenged the way it is and I
think this is what helps us to innovate. It helps us to create new things. And
without this idea of challenging the current implementation, let’s say, we would
never get iPhones where we just get rid of the keyboard or its NUM pad. It was
something typical for phones back then, but then someone famous said, “Hey,
let’s just get rid of it. Let’s just make it the single touch screen.” And
nobody would think that’s a great idea. And now every single phone out there,
it’s just one big touch screen.

[00:38:18] SY: That’s so true. Absolutely. Number three, my first coding project
was about?

[00:38:24] SE: Doing a 3D game in Borland Pascal.

[00:38:29] SY: Oh, cool!

[00:38:30] SE: Yes.

[00:38:30] SY: That sounds hard.

[00:38:31] SE: I know. But I was able to render a queue and I was so happy about
it because it required so many formulas that I had no idea how they work, but it
is what it is.

[00:38:45] SY: And number four, one thing I wish I knew when I first started to
code is?

[00:38:50] SE: That it isn’t about code. It’s really about people and
soft-skills and interactions and understanding people better because this was
crucial in making progress in my career that okay, I can learn every programming
language in the world, but unless I know how to communicate with people, be it
learning English or learning people’s emotions, I would never be where I am
today. So unfortunately, coding isn’t about code, but of course, some part of it
is.

[00:39:25] SY: Well, thank you again so much for joining us.

[00:39:27] SE: Thank you. I truly enjoyed the conversation.

[00:39:36] SY: This show is produced and mixed by Levi Sharpe. You can reach out
to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join
us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern
Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For
more info on the podcast, check out www.codenewbie.org/podcast. Thanks for
listening. See you next week



Thank you to these sponsors for supporting the show!







Thank you to these sponsors for supporting the show!