Hello. This is the Wadiz FE Development Team.
I’ve been interested in TDD (Test-Driven Development) for quite some time. But every time I tried to apply it, I felt a sense of helplessness that was hard to put into words. So I’d give up, only to try again later. However, not long ago, I realized that the root of that helplessness lay in my “perspective.” So I’d like to share my thoughts on that.
*TDD: Test-Driven Development
There are different perspectives on TDD, aren't there?
2003년 <다빈치 코드>라는 소설이 세상에 나오기 전까지, 레오나르도 다빈치의 <최후의 만찬> 벽화는 종교화였어요. 사람들은 이 그림을 종교적인 관점으로 보았죠. 하지만 <다빈치 코드>는 이를 전혀 다른 관점으로 해석합니다. 소설, <다빈치 코드>에서 <최후의 만찬>은 더 이상 종교화가 아니라 ‘비밀 메시지’였거든요.
By the way, did you know there are two completely different perspectives on TDD? They arethe “waterfall development” approachandthe “agile development” approach. As you might have guessed, I’ve come to believe that the reason we’ve failed in our attempts at TDD so far is because we approached it from the waterfall development perspective.
Shall we get into the details?
Software Entropy
The fundamental difference in perspective lies in the strategy (or concept)regarding how to manage software entropy.
관점 차이를 이야기하기 전에 먼저 ‘소프트웨어 엔트로피’라는 용어에 대해서 말씀드려야겠군요. ‘소프트웨어 엔트로피’는 <실용주의 프로그래머>라는 책에서 나오는데요. 소프트웨어 시스템 내의 ‘무질서’한 정도를 의미해요. ‘열역학 법칙’에 따라 우주의 엔트로피가 지속적으로 증가하게 되는 것처럼, ‘소프트웨어 엔트로피’도 ‘요구사항’의 변화에 따라 증가하게 되는데요. 폭포수 개발 방식과 애자일 개발 방식은 ‘소프트웨어 엔트로피’를 대하는 근본적인 차이를 가지고 있어요.
The waterfall development model assumes that it can manage most software entropy factors. Therefore, we invest time in developing the software and assign the responsibility of controlling “software entropy” to the developed software. In the figure below, the box with the yellow border represents the software release point. However, we cannot prevent software entropy from increasing. Consequently, a maintenance phase becomes necessary. Eventually, when software entropy grows to a point where it becomes difficult to control, the software must be redeveloped.
However, agile development doesn’t attempt to manage all “software entropy factors” at once. Instead, it brings in as much as it can handle at a time, and releases the software once it has evolved enough to be released. If we were to illustrate this, it would look something like this, right?
If waterfall development is like building a dam to manage water, then agile development is like creating a channel to manage it.
The Consequences of Difference
These fundamental differences in perspective give rise to a variety of distinctions. In particular, in the context of the testing we’re interested in, the “waterfall” approach is viewed as “contract verification,” while “agile” is seen as a “stepping stone toward evolution.”
I’ve summarized a few points regarding these two perspectives.
As you probably know, TDD is a method used in agile development to manage software entropy. It’s a step toward laying the groundwork for evolution. However, developers with a waterfall mindset tend to view TDD as a means of verifying contracts. That’s why TDD is hard to understand and difficult to apply. That’s why, despite my long-standing efforts to adopt TDD, I eventually gave up.
Reasons Why TDD Is Difficult
We aren't familiar with agile development methods. Instead, we're used to the waterfall development approach. So even when we try to do TDD, we end up approaching it from the perspective of the waterfall development method.
If you start viewing TDD solely as a means of verifying contracts, all other aspects of TDD disappear, leaving only unit tests. At this point, you find yourself struggling to write unit tests. However, because the market changes so rapidly (and for various other reasons), few projects begin with clearly defined “contracts.” This makes writing tests difficult.
What’s more, when writing tests for validation, it feels natural to write and implement all the code first, so that’s how we end up working. But that makes the code itself difficult to test. Plus, since we’re trying to validate code that’s already been written, it ends up taking twice as long. That’s why, even if you start a project determined to give TDD a try, you end up giving up in the end.
Even so, I just can't give up TDD.
Risks Associated with Changes in Requirements
<소프트웨어 스펙의 모든 것>에서 저자인 김익환 님은 ‘요구사항 오류 수정 비용’이 개발 프로세스 단계마다 다음과 같이 급격하게 증가한다고 밝히고 있어요. (스티브 맥코넬의 <소프트웨어 생존 전략>에도 비슷한 이야기가 나오는데요. 부정확한 요구사항이 50~200배의 비용을 지출하게 한다고 언급합니다.)
김익환 <소프트웨어 스펙의 모든 것>, P. 37
소프트웨어 개발이 끝난 다음 ‘유지보수’ 단계에 요구사항을 수정해야 한다면, 엄청난 수정 비용이 들어가게 되는데요. 이건 프로젝트의 위험 요소로 작용하겠죠. 이런 문제가 발생하지 않게 하려면, 어떻게 해야 할까요? 폭포수 개발 방식에서는 커뮤니케이션을 좀 더 정확하게 하려고 노력해요. 그래서 아주 체계적이고 세세한 문서를 만들어 내게 되죠. 김익환님의 <소프트웨어 스펙의 모든 것>을 읽어보시면 이 부분을 자세히 이해 하실 수 있을 거예요.
Why do requirements change?
First, there’s a good chance users don’t know what they want.
Henry Ford, often called the “King of the Automobile,” once said, “If I had asked customers what they wanted, I would have been raising faster horses.” Steve Jobs also said, “If I had asked users what they wanted, I would have built a faster DOS terminal, but I built the Macintosh.”
Users often struggle to explain how to meet their needs because they don’t fully understand the technology. So they say they need a faster horse or a faster DOS terminal. But what they really want isn’t a horse—it’s a means of transportation—and it isn’t a DOS terminal—it’s a user-friendly computer.
Second, the market is changing rapidly.
Market conditions often differ between the start and end of a software development project. In such cases, the project management team has no choice but to change the requirements.
Third, to be honest, there are limits to what developers can understand about requirements.
Given the two reasons mentioned above, there are inevitably limits to how well developers can keep track of constantly changing requirements. On top of that, developers must also keep up with evolving technologies. That’s why the waterfall development model attempts to control changes in requirements, viewing uncontrolled changes as risks. Agile, however, views changes in requirements as inevitable. It strives to embrace them rather than control them.
2000년대 초반에 알려지기 시작한 XP(익스트림 프로그래밍)은 애자일 개발 방식 중에 하나인데요. 켄트 백은 XP를 주장하면서 “변화를 포용하라”고 주문해요. 그리고 실천 방법을 제시하는데요. 거기에 TDD가 있어요. ( 강정배 외5 <정보처리기술사 이론과 전략 – 도메인2> , 82페이지 )
In other words, TDD can be described as a practice that Agile development uses to accommodate changes in requirements.
So, what is TDD?
앞에서 말씀드린 것처럼, TDD는 변화를 포용하기 위한 실천법이에요. 그럼, TDD의 교과서라고 볼 수 있는 켄트백의 <테스트 주도 개발>이라는 책을 한번 들춰 볼까요?
Predictable It is a viable development approach. You can know when the work will be finished without worrying about the endless stream of bugs. You getthe chance to learnall the lessons the code has to teach. If you rush to finish it exactly as you first envisioned, you lose the opportunity to think about a second, better version. The software you create improves users’ lives. Your colleagues will respect, and you, in turn, can respect them. It feels good while you’re writing it. If you can sufficiently reduce defect density, you can transform quality assurance (QA) from a passive task into an active one .. If you can sufficiently reduce the number of nasty exceptions, the project manager can make accurate estimates, allowing them to involve the client in the daily development process. If the topics of technical discussions can be made sufficiently clear, software engineers can collaborate in collaborate on a minute-by-minute basis.
This is a story Ron Jeffries shared. In short, he’s saying that everything improves when you practice TDD. If Ron Jeffries’ claim is true, we can’t afford to ignore TDD. Now, let’s break down those “improvements” into two categories: the company and the developer.
Why Companies Need TDD
First, predictability
훌륭한 소프트웨어 개발을 정의하면 ‘필요로 하는 것(요구사항)을 주어진 시간(일정)에 그리고 주어진 비용(인력)으로 제공하는 것’이라고 해요. (댄 필로네 외1 <Head First Software Development>) 다시 말해, 개발 일정을 지키지 못하면 훌륭한 소프트웨어 개발이라고 볼 수 없는데요. 폭포수 개발 방식은 70% 이상이 일정을 지키지 못한다고 하네요. 게다가 요구사항이 왜곡되어도 복구할 방법이 없는데요. 다음 카툰에서 이를 상징적으로 보여주고 있어요.
*이 그림의 원전은 작자 미상으로 처리하는 경우가 많은데요. 제가 알고 있는 가장 오래된 언급은 J House라는 컨설턴트가 블로그(2008년)에 인용한 거예요. 하지만 블로그에 언급된 Phil Hord의 링크는 현재 끊겨 있습니다. 위 링크는 2011년에 출간된 <소프트웨어 아키텍트가 알아야 할 97가지>라는 책에서 언급하고 있는 링크에요.
The user had wanted to make a swing by attaching a tire to a tree, but since the instructions were given as shown in the first picture, the project ended up with an unpredictable outcome.
Second, cost savings
로버트 C 마틴은 <클린 아키텍처>에서 실질적인 프로젝트를 예로, 일반적인 프로젝트의 비용이 증가하는 것을 설명하는데요. 개발자 인원이 증가하지만, 그만큼 생산성이 감소하고 코드 라인 당 비용이 증가했음을 보여주고 있어요. (보고서에 따르면, 8차례에 걸쳐서 프로젝트를 진행했는데 마지막에는 비용이 40배나 증가했다고 하네요.) 로버트 C 마틴은 TDD로 이런 비용 증가를 막을 수 있다고 설명해요.
Third, reduced development time
역시 <클린 아키텍처>에서 나오는 이야기인데요. TDD를 하면서 개발 시간이 줄었다 합니다. 코딩하고 테스트까지 하니, TDD를 하면 개발 시간이 늘어나지 않을까 싶은데요. 이건 우리가 폭포수 개발 방식의 관점으로 TDD를 보기 때문이에요. 하지만 TDD를 제대로 하면, 코딩과 테스트가 다른 과정이 아님을 알 수 있습니다. 게다가 몇 가지 이유 때문에 TDD로 코딩하면 코딩 속도가 더 빨라지게 돼요. 이는 앞으로 상세히 말씀드릴게요.
The second of Wadizfive principles is “We lead the way while enjoying the rapidly changing currents.” This seems to align with the Agile Extreme Programming (XP) development methodology, which emphasizes “embracing change.” I believe TDD is a truly essential practice for Wadiz —that is, for the company.
Why Developers Need TDD
2002년 애자일의 ‘플래닝 포커’를 개발한 제임스 그래닝은 <임베디드 C를 위한 TDD>에서 TDD의 장점을 다음과 같이 정리하고 있어요. ‘버그 감소’, ‘디버깅 시간 단축’, ‘부대 효과 side-effect 결함 감소’, ‘거짓말하지 않는 문서들’, ‘마음의 평온’, ‘더 나은 설계’, ‘진척 모니터’, ‘재미와 보상’. 하나씩 살펴볼까요?
1. Fewer bugs
In simple terms, a program (in the imperative paradigm) can be described as a “sequence of commands that manages the state of the software.” So, when state management becomes complex, bugs inevitably arise. Therefore, it’s necessary to keep state management simple. If you write tests first, you’ll end up creating functions that modify just a single state to make the code testable, which keeps the code simple.
2. Reduced debugging time
디버깅 시간이 길어지는 이유는 버그의 위치를 찾기 힘들기 때문이에요. TDD를 하면, 버그가 생기자 마자 버그의 위치를 알 수 있거든요. 당연히 디버깅 시간이 줄어들죠. 그래서 <xUnit 테스트 패턴>의 제라드 메스자로스는 “회귀 테스트가 설치된 코드에는 코드 체크인을 하기 전, 테스트가 버그를 찾아주므로 더 이상 버그가 생기지 않을 것이다”라고 이야기했어요.
3. Sunny Day Test
<레거시 코드 활용 전략>의 마이클 페더스는 “이들은 여러 가지 특별 조건들을 테스트하지 않고 특정한 동작이 존재하는지를 검증할 뿐이다.”라고 말했는데요. 다시 말해서, 화창한 날 테스트의 의미는 코딩을 다 해놓고, 결과 테스트만 한다는 말입니다. 그렇게 하면 코드 내부에 결함이 있어도 찾을 수 없으니, 나중에 문제가 되겠죠. 화창한 날 테스트를 극복하는 방법은 TDD 뿐이에요.
4. Reduction in the number of bugs
산드로 만쿠소는 <소프트웨어 장인>에서 “테스트 주도 개발 방법론에 익숙해지고 레거시 코드에 테스트를 만들어 넣은 이후로는 코드 자체를 디버깅해야 하는 상황이 손에 꼽을 만큼 적었다”라고 말하고 있어요.
5. Good Code
켄트 백도 <테스트 주도 개발>에서 “일상적으로 격리된 테스트를 하는 습관을 들이기 전까지는 어떻게 하면 이렇게 응집도를 높이고 결합도를 낮출 수 있는지 정확히 이해할 수 없었다”라고 하고 있죠.
6. Documents That Don’t Lie
When working on a project, you end up creating a lot of documentation. However, documentation about code is often meaningless, because while documentation is difficult to change, code is constantly evolving. If you use TDD test code as documentation, it will be updated along with the code, ensuring that the code and documentation are always in sync.
7. Better Design
What makes a good design? It’s a design that creates a structure that’s easy to maintain. For a program structure to be easy to maintain, it must be easy to test. That’s why Test-Driven Development (TDD), which involves writing tests first, leads to a better software structure.
<애자일 마스터>라는 책에서는 테스트를 설계를 구성하는 수단으로 사용한다고 했고요. <Head First Agile>이라는 책에서는 팀에 책임이 따르는 마지막 순간에 설계에 대한 의사결정을 내리라고 조언하고 있어요. 마지막 순간은 결국 구현 코드를 입력하는 시점이죠. 게다가 <엔터프라이즈급 애자일 방법론>에서는 “테스트하기 어렵다면 주로 설계 개선이 필요하기 때문이다”라고 말하는데요. TDD로 만든 테스트가 설계 구조의 리트머스 시험지 역할을 하는 것을 알 수 있어요.
8. Fun
코딩이 재미있는 이유는 뭘까요? 약 50년 전 프레드릭 브룩스는 <맨먼스 미신>이라는 책에서 코딩의 즐거움을 몇 가지 소개했는데요. 퍼즐을 푸는 즐거움이 있다고 했어요. TDD는 소소한 퍼즐을 푸는 느낌을 주거든요.
So why is coding so uninteresting? It’s because it’s complex. It’s complex because the moment you start writing code, you have to think about too many things at once. Martin Fowler says that practicing TDD feels like juggling a single ball. That’s how much simpler the code becomes. Plus, when you read someone else’s code and find it so complex that it’s hard to understand, it’s frustrating. If the code is written using TDD—meaning it’s simple and backed by tests—that won’t happen.
9. Compensation
‘1만 시간의 법칙’은 세계적인 저술가 말콤 글래드웰이 <아웃라이어>에서 언급해서 유명해진 용어예요. 전문가가 되어 성공하는 단계에 이르려면 적어도 1만 시간의 시간이 필요하다는 말인데요. 말콤 글래드웰이 이런 이야기를 하게 되었던 심리학 보고서를 작성한 사람은 안데르슨 에릭슨이지요. 에릭슨은 <1만 시간의 재발견>에서 1만 시간을 보내는 것보다 중요한 건, ‘목적의식 있는 연습’, ‘의식적인 노력’으로 1만 시간을 채우는 것이라고 이야기하고 있어요. 피아노를 접하고 1만 시간을 보낸 것이 아니라, 피아노 레슨을 받고 연습하며 1만 시간을 보내야 피아니스트가 되는 원리와 같아요.
So what do “purposeful practice” and “conscious effort” mean for a developer? Isn’t it the practice of writing programs with a structure that’s easy to maintain? Since developers make a “conscious effort” to write good code while practicing TDD, engaging in TDD can ultimately be seen as a way to accumulate the 10,000 hours needed to become a true coding expert.
So, I guess I should do TDD.
Getting Started with TDD
Test-Driven Development (TDD) follows the cycle shown in the figure above. 1) First, you write a test that fails, 2) then you implement code that makes the test pass, and 3) finally, you refactor the code.
This is something you come across right away when you Google TDD. It’s hard to really grasp, isn’t it? It makes you want to hear a more in-depth explanation.
I joined Wadizin late 2019. I wanted to talk about TDD. I was looking for an explanation that would help me gain a deeper understanding. Then, in December 2019, I happened to come across a tweet byRobert C. Martin. (Robert C. Martin is famous for his “Clean” series of books, including *Clean Code* and *Clean Code: A Guide to Clean Code*.) Reading that tweet helped me understand TDD on a deeper level. To summarize, it goes like this:
Don’t commit code without failing tests
Stop writing tests if an error occurs
Stop coding immediately if a test fails
Iterations after refactoring
One cycle lasts 10 to 60 seconds
The last point really hit me hard. If you can write a failing test and a passing code, then refactor it all within 10 seconds, that’s not the kind of testing I’ve been thinking about. In other words, if you’re writing “tests that verify contracts,” it’s impossible to complete a full cycle in 10 seconds.
What You'll Need for TDD
What do I need to prepare to practice TDD with a cycle time of 10 to 60 seconds?
First, we need to change our perspective on the development process and testing.
As mentioned earlier, TDD is not just about unit testing.
Second, we need a tool that allows us to quickly write tests and code.
Of course, we could do this manually. But wouldn’t it be faster if we could use a code template? Since the Wadiz development team uses VSCode extensively, we looked into whether we could add an extension to it. Surprisingly, the documentation for extensions was quite thorough, so it seemed like adding a simple extension would be easy with just a little study. So we decided to give it a try.
This is an extension that creates a React component directory and files for you once you provide a name. You don’t necessarily need to create one yourself, as there are many publicly available extensions.
Third, I need to set up a watch for the test and have a console that continuously displays the test results.
As soon as you enter a test or some code and save it, it appears right in the console. Most React environments are set up with Jest for test watching, so all I had to do was open it in a console like iTerm. (Just imagine tests whizzing by on one side of the screen every time you save your code…)
Fourth, you need to be familiar with test syntax.
If you need to enter tests quickly but don’t know what to type, it’s hard to finish a cycle within 10 to 60 seconds. Plus, coding projects always have deadlines. It was just too much of a hassle to try to do TDD by looking up test cases and entering them step by step.
Before you begin
I’ve looked through quite a few books on this topic. It’s best to keep the following three points in mind as you get started.
Unit testing: Tests should be kept as small as possible.
Isolation of the test subject: The test subject must have no dependencies on other UI components.
The role of test documentation: We need to ensure that other developers can immediately use the code we’ve written just by reading the tests, even without any other documentation.
While working on this project, I decided to try implementing TDD. However, since I wasn’t familiar with the syntax and commands for writing tests, I spent a lot of time looking them up. As a result, I realized that if I were to fully commit to TDD, I wouldn’t be able to finish the work within the deadline. I then wondered what I could do to implement TDD more effectively on my next project. I realized it would be helpful to research methods for “isolating the test subject” in advance. So, I started by looking into “isolating the test subject.”
There are three main ways in which UI components develop dependencies: parent components, child components, and hooks.
First, resolving parent component dependencies
I suspect that the parent components affecting all areas are likely Redux and React-Query. The Wadiz development team is currently in the process of transitioning from Redux to React-Query. So, I created the following parent component for testing purposes.
<ReactRedux.Provider store={store}>
<QueryClientProvider client={queryClient}>
{children}
</QueryClientProvider>
</ReactRedux.Provider>
I considered including React Router as well. However, there are quite a few UI components that don’t use it, and since the specific test cases I wanted to run differed slightly depending on where it’s used, I decided not to include it.
The next set of parent components we needed to consider were form-related components. The Wadiz development team uses react-hook-form extensively. The form in react-hook-form is structured so that child components can manage the values to be entered into the form independently. Therefore, we needed a way to test components that depend on the form. As we implemented the tests, we realized that testing became much easier if we could simply set the `defaultValues` to match our testing intentions. So, we wrapped the component under test with the following code:
const methods = useForm({ defaultValues });
return (
<FormProvider {...methods}>
<form id={formId} onSubmit={methods.handleSubmit(jest.fn())}>
{children}
</form>
</FormProvider>
);
With this level of preparation, most dependencies on the parent component are usually resolved.
Second, resolving dependencies in child components
I found that simply importing and using child components as-is often led to test code becoming overly complex due to dependencies within those components. So, I created mock versions of the child components using jest.mock.
jest.mock('./components/CategorySelect', () => ({ CategorySelect: () => <></> }));
If you add this code and import the component under test, when that component imports ‘./components/CategorySelect’, it will retrieve the `jest.mock` object. Since the child component becomes a mock object, it becomes easier to test parts of the component under test that are related to the child component (such as changing props or detecting callback calls, etc.).
Third, hook dependency
I won’t go into detail about React hooks themselves. I looked into whether there was a way to test hooks, and sure enough, there is.
import { renderHook } from '@testing-library/react-hooks';
It worked fine when I passed the function to be called by the hook and the wrapper in which the hook would be invoked to `renderHook`. Using `renderHook` was also useful for testing the API functions and mutations that `react-query` calls. Since the senior developers on our team use MSWand many examples rely heavily on it, I decided to give MSW a try myself.
Where should I start?
Now that I’ve figured out how to isolate the UI components I want to test, all that’s left is to figure out how to write the tests. How can I write code while incorporating tests? That’s when I realized that “outline comments” are quite useful.
다음 그림은 켄트 백의 <테스트 주도 개발> 29장의 ‘테스트에 대한 짧은 아웃라인’ 예시입니다.
Back when I used to code in C, the most common approach was to create dummy functions for the main features I wanted to implement. If I wrote down what needed to be done, I could see how to break it down and implement it. Then I’d break it down further… and so on. I’d structure the code in this top-down manner. So, a “brief outline of the test”—which involves writing down what needs to be done—seems like a good starting point for testing. So, the coding process will proceed in the following order.
Generate default code using the code generator (VSCode extension)
Open the test file and summarize the functionality of the component you are creating in the comments (as a brief outline)
Writing tests that fail as I remove comments one by one
Enter the code to ensure the test succeeds
Refactoring
Go back to step 3 and repeat
If we can develop the ability to solve problems 3 through 5 in 10 to 60 seconds, I think we’ll really get a taste of what TDD is all about 😀
How should we move forward from here?
CI/CD is not a build system
Another misconception stemming from the waterfall development perspective is viewing CI/CD as a “build system.” CI stands for Continuous Integration. From the waterfall development perspective, it’s natural to think of integration as something that’s done carefully at the end of the process, once all work is complete. However, from the agile development perspective, we must continuously integrate to adapt to changes.
<이펙티브 엔지니어>라는 책에서는 더 효율적인 개발 문화에 대해서 이야기하는데요. 여기에 페이스북의 CI에 대한 이야기가 나와요. 1,000명이 넘는 개발자가 하루 2번 코드를 배포할 수 있는 시스템을 갖추고 있다고 하네요. 더 나아가 ‘웰스프론트’라는 회사에 대해서도 소개하는데요. 10억 달러 이상의 고객 자산을 관리하는 회사인데도, 2014년 6월을 기준으로 매일 30회 이상 코드를 배포했다고 하더군요. 만약 제대로 TDD를 한다면, 테스트 코드 커버리지가 90%를 넘게 될 테고, 그런 상황에서 e2e 테스트까지 잘 갖춰져 있다면, 코드의 작은 변화는 자동화 테스트만 거쳐서 배포하는 게 가능하겠죠. 그러면, 하루에 30회 코드를 배포한다고 해도 안정적인 서비스를 제공할 수 있게 될 테고요.
What will I be able to do?
엘리 골드렛은 <더 골>에서 ‘제약이론’이라는 걸 주장했어요. 생산 시스템 전체의 생산성은 사실상 ‘병목구간’에서 정해지는 것이기 때문에, 이를 개선하려면 그 구간을 찾아 개선해야 한다는 거죠. 이 논리는 사용자의 요구사항이 개발자들에게 전달되어 구현되고 배포되는 일련의 과정에도 적용해 볼 수 있어요. 시장의 변화가 사용자의 요구사항이 되어 개발자들에게 전달되면, 시장 변화 속도에 맞춰 배포까지 진행되어야 안정적인 시스템이라고 볼 수 있는데요. 한 구간에서 이를 해결하지 못하면 병목구간이라고 볼 수 있습니다.
Let’s take a closer look at the “waterfall development model.” The waterfall model views the process as a series of stages rather than a continuous flow. As a result, the process comes to a halt until each stage is completed. In other words, if requirements change before the entire waterfall development process is finished, the waterfall model inevitably becomes a bottleneck.
A company that can quickly adapt to changing demands will be able to evolve just as quickly and provide better services. I think Kevin Systrom’s “Bourne” is a prime example of this. In 2010, Kevin Systrom developed a location-sharing app. It was an app that allowed users to take photos of specific locations and post reviews using their smartphones. However, since a location-sharing app called ‘Foursquare’ was already on the market, the response wasn’t very positive. Then, the ‘Bubbon’ developers noticed something unusual: users were turning off Bubbon’s location-sharing feature and using only the photo feature, which was an additional function. So, the Bubbon team decided to revamp the app. They removed the location-sharing feature, kept only the photo feature, and re-released it. They also changed the app’s name to “Instagram.” Two years later, the company was acquired by Facebook for 1.2 trillion won.
To adapt to rapid market changes, you need the ability to evolve just as quickly. TDD is the most fundamental technique that enables development teams to do just that.
In closing
The Wadiz Front-End Development Team holds voluntary technical seminars. I also discussed TDD—which I’ve explained in this post—during one of these sessions, and all the developers on the team showed great interest. Thanks to that, I’ve decided to actively give it a try starting with this project and make sure I master TDD.
If we shift our perspective on TDD and practice until we can complete a cycle every 10 to 60 seconds, I believe we’ll gradually become better developers. And if we make these small changes together—not just me, but all the developers on the FE team—I’m hopeful that the entire Wadiz development team will evolve into an organization with an outstanding development culture.
I think Wadizwill ultimately serve as the cornerstone for staying ahead of the curve and embracing the rapidly changing currents!
Do you still have any questions? 👀
See how developers work 👉 Click here
