Hello everyone. I presented at a spring camp in 2017, and now, seven years later, I am here again. Time really flies. Back then, I talked about techniques like event sourcing and CQRS, but today I would like to introduce a testing tool. I used to frequently give presentations at conferences, but due to COVID, most of these conferences disappeared, and I stopped doing them as well. Personally, I have been quite busy, and as a result, I feel like I've lost touch with how to effectively communicate my ideas so that the audience can gain valuable insights. While preparing for this presentation, about two weeks ago, I mentioned to the organizers that I was planning to present something like this, but their reaction was that they didn't understand what I was talking about at all. So...

Oh, this is a big problem. Did I choose the wrong topic, or did I prepare the content too difficult? So, if possible, I tried to simplify and modify the content a bit, but I'm not sure if that will be enough. Therefore, instead of providing you with a lot of knowledge about this tool, I thought it would be nice to create an atmosphere where you can enjoy yourselves since the weather is nice. 

I did something similar during my presentation at the spring camp seven years ago. Nowadays, I notice that some people still do this—taking photos of the slides during presentations. The source code for the slides is all available, so feel free to take pictures. These days, when you take a photo, the camera can immediately recognize the URL and link you to it. You can see everything here, so while I'm talking about the presentation...

이제 사진을 안 찍으셔도 될 것 같아요. 그리고 이건 한시적 공개가 아니고 앞으로도 계속 공유될 테니까 링크를 사용하시면 될 것 같습니다. 자, 그래서 제가 테스트 도구를 설명하기 위해 예제 코드를 만들어 봤어요. API 서버를 하나 만들어 봤는데, 물론 현업에서 쓰이는 만큼 높은 복잡도를 가지고 있지는 않지만, 그래도 너무 장난감 같지 않도록 최대한 그 밸런스를 맞추려고 노력을 해봤습니다. 커머스 플랫폼 서비스라고 가정하고 만들었고, 양쪽에 사용자가 있습니다. 구매자와 판매자가 있고, 둘 다 UI를 사용해 접속합니다. 구매자는 구매자 UI를 사용하고, 판매자는 판매자 UI를 사용하게 됩니다. 그래서 이번에 제가 샘플로 만든 코드는 서버인데요, 몇 가지 기능이 실제로 구동되기 위해 로그인부터 상품 등록하고 검색하는 기능까지 동작하긴 하는데, 그걸 오늘…

I won't say everything, but there are only 42 minutes left, so I would like to introduce just a little bit. While doing this, I want to share that after learning TDD, I write almost all my code—over 99%—using TDD. However, I also faced some inconveniences while writing TDD, and I will talk about what tools I used to solve those issues.

First, I want to discuss random test data. When I was developing this system and creating this example application, I also used TDD from the beginning and wrote the tests first. However, I think there might be some people who don't know what TDD is, so let me briefly explain. TDD involves writing a very small piece of code, assuming that you first write the test code to validate that code. After that, you write just enough production code to pass the test.

After passing the test, I created a test code to test a small function, and then I wrote just enough operational code to pass that test code. This technique involves continuously repeating very small cycles to implement the code. The first unit test was like this: if you look at the name of the unit test, it states that if you use the correct information to make a request, it returns a success status code. In this class with the test method, the class name is PostTest, and from the display name above, you can understand that it is a test for making a POST request to the API consumer signup URL path. Therefore, I wrote a test stating that if you use the correct information to request this API consumer signup API, it returns a success status code. I created the app using Spring Boot, and the necessary code for Spring Boot testing is included. Then, looking at the test method, I first specify the path for the API call and the commands needed for the API call.

I set up an object called sign up and created it with an email like user@test.com and a password my password. After that, I used a tool provided by Spring Boot for testing, using a variable named client to send a request. Then, there should be a response, and I need to check whether the response status code indicates success, which is a code in the 200 range. The minimal code necessary to satisfy the test we just looked at is this much. I found that if I write just this code, the test passes. Without this code, a 404 code is returned because there is no actual API to handle it, so it can only return with that post mapping. When I ran the test, it succeeded. Next, I wrote the second unit test. This time, the functionality I want to validate is that when using an already existing email address, the request should return a 400 Bad Request.

I hoped to be returned, so I designated the pass again and wrote an email to sign up. After doing this once, I would try it again. After changing the password, I would request using the same email. Then I would check that the response code is 400. The code that would satisfy the second test could not be done with just the same kind of code as before. Now, I need to record the email somewhere, so that when a new request comes in, I can check for duplicate emails. So, I created an entity using JPA and included the email property. After that, I added various functionalities to the API action method, which was previously just a shell. I injected the JPA repository dependency and, when saving, since we applied a unique index to the email, we cannot have data with the same email.

If you try to insert it, an exception will occur. So, when the exception occurs, it returns a bad request. I just ran the second unit test that I wrote. However, when doing TDD, after satisfying a test, you should not just run the recently written test; you need to run all the tests that have been written so far. This is because while trying to satisfy the newly written test, you might cause a failure in a previously written test. When I ran both tests, one failed and one succeeded. I wondered why. When I executed them individually, they succeeded, but looking at the test execution log, I found something. It showed a unique index, and it seemed to work as we expected, but why is that? This situation is often referred to as a false positive.

The term was not created in a specific context but is rather a term developed in statistical experimental theory. What it means is that a positive result indicates that the test has failed. When a test verifies something unusual, we refer to that as a positive response. Therefore, we call it a positive. A false positive means that the positive result is incorrect; it indicates that there is an issue with the operational code. The test produced a positive response, but in reality, the operational code is functioning correctly. When the operational code is correct but the test fails, we refer to it as a false positive. We call it a false positive. 

So, why does a false positive occur? It happens because the email address used in the test code is the same. It tests with the email address user@test.com. Therefore, if you request using an already existing email address, and if this test runs first, there will already be an entity existing with the user@test.com email.

Then, when the test above is executed, if we look at just one test case, it seems that the correct user information has been entered. However, in reality, the data from previous tests remains, which leads to false positives. To resolve false positives, we can modify the test code to use random data to create emails every time a test is executed. This way, false positives are eliminated, and when we run the tests again, all of them succeed. 

I have thought about the reasons for using random test data. Next is the business rule. When we write tests, there are various aspects to consider, but one aspect that I believe is very important is that test code is a technique to express system requirements. Requirements can be illustrated in a drawing, recorded in Notion, or represented through diagrams, among other methods.

One method among these is to write this code. The test code must contain the business rules. For example, there is a seller entity that looks like this. It may be simple, but there can be several business rules. For instance, the type of the email attribute must be a string, but it cannot just be any string. It should be a string that matches the email format. This is also very simple and quite obvious, but it is a business rule. 

Next, regarding phone numbers, the type must also be a string, and it cannot just be any string. In the system we are dealing with, we will always use a format like 010-xxxx-xxxx. This format must be used as well. Although this is very small, it is a business rule. Among the features we are developing, there is a function that retrieves only the list of products registered by a specific seller.

There is a query function like this. I expressed this query in code. I specified a query type called Get Product of Seller, and this query includes the seller ID. Next, I also created a query processor type to execute this query. This query processor defines and uses the entity manager interface, which is now implemented. It takes the query as input and returns a list of product views. This means it will return all products associated with the seller ID contained in the query. 

So, what does the product view look like? It looks like this: a product view has an ID, a seller, and the seller is of the seller view type. The seller view type contains the ID and the seller's username. Now, to create this query processor, I will do TDD, so I need to write tests. These are the requirements for the query.

There are various requirements for the processor, and I will express one of them. Products owned by other sellers should not be returned. Therefore, we should only return the products associated with the seller ID in the query. We will write a test for this, and the test name will be Do not return products owned by other sellers. This is a requirement, and to fulfill this requirement, we will use Spring Boot tests to inject the necessary objects such as the Seller JPA repository, the Product JPA repository, and the entity manager. Next, we will create a seller entity using random data. To generate the seller entity randomly, I created a random object. Then, I set a random email and a random username for the seller entity, while the password is not currently important, so I set it as password. After that,

I created a phone number like this: 010 followed by some digits. After that, I save it to the repository. Next, I will create a product owned by the seller I just created. To do this, I need to make a product entity, and at that time, I will use the getId of the seller entity I just created as the second parameter to set the seller ID in the product entity. Do you understand? 

Next, let's create another seller. If we only have one seller to structure the data, it might be difficult to validate the tests, right? So, I will create another seller. I will also create a seller entity and generate random data for it. After saving it, I will create a product owned by this other seller. Looking at the second parameter, it is now set to the target object. Then I will proceed with the query.

We will create an object and execute it. The term SUUT refers to the system under test, defined in the unit pattern. This means the subject of the test, such as a system, class, or object method. So, we create a SU and call the SUUT process. After that, we validate the results. We check if the seller IDs of the returned objects are indeed seller IDs. If we break this down, we get code that looks something like this. Here, we have expressed a requirement in code. Some people might think, Well, that looks plausible, but others might say, Wow, it takes this long just to do one thing; testing is really a pain and it eats away at our mental health. I also thought that way. So, I would like to introduce one of the various solutions I use: a library called AutoPagi.

This is the project that I have started and am currently contributing to the most. I will take a moment to make an announcement. Yes, I have created two courses for Fast Campus: The Red. One was made in 2021, and the second one was made in 2022. Since this is not related to today’s presentation, I didn’t include slides for it. However, I am preparing a lecture that specifically covers TDD related to Spring Boot. 

Now, how is this related to the presentation? Well, the right side is not related, but the left side is. I created the first lecture in early 2021. To avoid focusing solely on a specific programming language, I mixed JavaScript, Java, and another language in roughly equal proportions. At that time, in 2021, I was working at a company called Tripstore, and I transitioned to a company in Gangnam. Currently, I am at...

Wide Company has used three languages, with Kotlin being the most utilized, and then Java and C#. The ratio of C# was the smallest, while Kotlin and Java were quite similar. The addition of C# was primarily for creating a small system later on, and most of the code is in Java and Kotlin. When I joined the company, about 80% was Java and the remaining 20% was Kotlin. So, I moved to a company that mainly uses Java JV1. At that time, I was recording a TDD lecture, and although it wasn’t my first time, it had been a while since I had created tests using TDD. I realized that I had these experiences recently. In fact, the testing tools for C# are relatively well-developed compared to Java. While Java also has its strengths, the C# side is better equipped.

I find myself in a more comfortable environment, and that's how it is. I can drive a Sonata without any issues, but if I were to switch from a Bentley to a Sonata, I might struggle a bit, right? Oh, I actually don't know much about cars since I don't even have a driver's license. So, it can be quite frustrating. I thought it would be great to have a convenient testing tool like the one in the Dannae ecosystem, so I looked for it, but there wasn't anything available. There were some similar tools, but they either weren't operational or didn't exist. I was very familiar with a tool similar to Auto Fixer in the Dannae ecosystem, and I thought it would be great to have a tool like that, especially for my unit testing in Java. That's when I started the Auto Pro project.

At that time, I could feel a sense of urgency. I started the project on March 6, 2021, and joined Gangnam Money on March 8. So, I made my first commit two days before I officially joined, and within a week, I made the first deployment. I thought to myself that I needed to create something right away. This is how the project began. I will explain what functions Auto Param performs a bit later. The current version of Auto Param is 8.3.0, and I have created about three versions. You can install it like this, and if you visit the Auto Param GitHub project site, the installation methods are explained in more detail. Earlier, I mentioned a test case using random email generation, and I wrote the code to eliminate false positives. If we look at it again, it looks like this. There is an annotation called Auto Source provided by Auto Param.

Here we are using a test annotation provided by the J unit. Besides the test annotation, there is another annotation called parameterized test that this unit offers. You can use this parameterized test together with another annotation called auto source, which is provided by AutoFixture. So instead of using the test annotation, you use the parameterized test annotation, and you also add the auto source annotation together. Then, the auto source can provide parameters to the method that is annotated with the parameterized test. Now, I created some arbitrary data. So when creating a command called sign, instead of directly instantiating it like before, I can just request it with the sign-up parameter. Then, the auto source will be created. The rest of the test code remains the same.

The code can be summarized in about three lines. The second test also requests a signup object, and when you simply request a password, the auto parameter generates random data. Looking at the execution results, since this is a parameterized test, you can see which parameters were used in the execution results. If you look at the email where the signup is created, you can see that it's not just a random string; it has @test.com attached at the end. This is because, even though the parameter name is email, the auto parameter thinks that if the name is a string type with email, it might be better to create it in an email format. I'm creating a lot of slides, and I'm worried that I won't be able to finish on time, so I'm moving very quickly right now.

I’m not sure if you’ll understand this well, but let me try. So, regarding the second case we talked about earlier, it involves a product owned by another seller. I apologize, but it doesn’t return the test as written. If you use AutoParam to create the test, you can do it like this. It has become much more concise, right? Let’s take a look line by line. First, I introduced the AutoSource station, and this time we have AutoDomainSource. I will explain this in more detail shortly. 

First, the seller enters the information. AutoPagi generates it randomly and creates the necessary entities. Then, the seller declares it again. Below that, AutoPagi uses random data to create a new entry. This time, the product entity was not requested directly.

I requested a factory that can generate products. I will explain how it is used shortly. Next, these three items are the dependencies for Spring Boot tests that we have seen in previous tests. First, the code that is executed saves the seller provided by the email in the repository. After that, we will mainly create a product entity, which receives the seller ID as the second parameter. This means we need to manipulate the seller ID according to the testing environment. To do this, we apply a customizer to the factory object that creates the products. This extends the functionality using the Auto-Page API, calling the freeze seller ID method to apply something that has been created.

If you customize the factory, what happens? After this code is executed, when the factory creates a product entity, the seller ID attribute will use the ID from the seller entity. I will explain how the freeze seller ID method works later. Once you have customized the factory, when you call the factory to create a product entity, the seller ID of the generated entity will be set to the ID of the seller entity mentioned above. This is how the product is added. 

Next, it is similar; you need to save another seller entity in the repository. Then, this time, you freeze the seller ID with the ID of another seller. After that, you create the product and save it in the repository.

Now, a seller's profile has been saved in the profile repository, and then a product related to that seller has also been saved in the product repository. After that, the process is similar. We create a query and execute it. Then, we test and verify the results. We validate the results of the product view list. For that seller, we can obtain the seller's ID, which is the ID of the seller who created the product. We check if only the seller's ID exists and not any other seller ID. In this way, by using Topaz, we can utilize existing data and simplify the process of preparing test data. Now, let me explain the core part of the AutoParam internal architecture. This might be a bit boring, so I'll try to proceed quickly. First, the resolution...

There is a class called Text. This class contains the most important content and provides two main methods: the Retrieve method and the Customize method. The Retrieve method takes an object as a parameter and returns an object. The object query contains information about what kind of object I want to obtain, and the corresponding object is created by the Retrieve method based on that query. 

Next, the Customize method allows us to modify the behavior within the resolution context. This way, we can inform the auto-processor of the business rules defined by our application, similar to how we previously froze the seller ID. Such modifications can be made in this manner.

The method mainly does two things. First, it generates, and then it processes. The generator creates a new object that didn't exist before, while the processor is used to manipulate an already created object. After that, it returns the result. The customizer takes the customizer input and uses it to replace the generator, meaning it plays the role of creating some object. If you pass the existing generator to the customizer, it returns a new generator. The same applies to the processor. If you pass the existing processor to the customize method, the customizer creates a new processor. In this way, you can continuously expand the generator and processor. It might be hard to understand, so I drew a picture to illustrate it. Here is the resolution.

When there is a context and an object query is input on the left, the generator first uses the object query to create an object. After it is created, it is returned, but before the return, the processor manipulates the created object in some way. The customizer provides the ability to replace the generator processor that has the object generation context. This is the core architecture of Auto-Pharangi. 

Now, the object query looks like this. There is only one interface. What is the type? What type of object do you want to create? This is a function that allows you to specify that. The most basic implementation of the object query interface is the type query, which is a class. Then, there is also a parameter query. The parameter query returns the type of the object, but especially...

The desired object is an argument of a certain parameter, which can indicate that it is an argument. Then, it allows access to various pieces of information that the parameter holds. Next, the object generator returns an object container. The object container is similar to an optional type, but the difference is that an optional type does not accept null values. If you input an optional null, it recognizes it as a failure. On the other hand, the object container accepts null as a valid value. Therefore, you cannot use optional directly, and the object container will create a type. First, the object container has three methods: one is unwrap, which returns whatever is contained in the object container if it holds something; otherwise, it throws an exception. The second is related to the optional map.

같은 역할을 합니다. 그러니까, 펑터라는 거죠. 프로세스는, 오브젝트 컨테이너가 뭔가를 담고 있다면, 프로세서 펑션을 사용해서 가공해낸 값을 가지고 있는 또 다른 컨테이너를 반환합니다. 만약에 컨테이너가 비어 있다면, 빈 컨테이너를 반환합니다. 옵셔널 맵과 거의 비슷한 기능을 수행하죠. 다음은, 이게 옵셔널 A, 이런 기능이 있었던 것 같은데 기억이 잘 안 나네요. 컨테이너가 비어 있지 않다면 자기 자신을 반환하고, 컨테이너가 비어 있다면 새로운 컨테이너를 서플라이어를 통해서 생성하여 반환합니다. 재미없죠? 넘어갈게요. 자, 오브젝트 제너레이터는 커리와 레졸루션 컨텍스트 두 개를 받아서 오브젝트 컨테이너를 반환하는 역할을 합니다. 그러니까, 뭔가 생성해내는 역할을 담당한다는 거예요. 그런데 모든 오브젝트 컨테이너가 모든 커리를 수용할 수 있는 것은 아닙니다.

There isn't a specific query that can be accepted. Therefore, if I can accept a query, I can create something, put it in an object container, and return it. However, if it's a query I don't know, I can't handle that. In that case, I will return an empty container. The various resolution containers have object generators that perform a wide range of functions, composed of object generators with different capabilities. For example, if I can create an integer type, I will accept a query for an integer type, generate an integer value, and if I can't, I will return an empty result, saying I don't know. Then, the resolution context will ask other generators, Can you generate this? If they can't, they will proceed to the next one and continue asking in this manner across multiple object generators.

We're asking about how to generate an entity. The function we saw earlier, called freeze seller ID, uses an object generator implementation. Earlier, we simplified the usage by creating a static function, so it was a bit easier to understand. However, in reality, when you call the method freeze seller ID, you input a seller entity. This means that you're actually creating an object called seller ID freezer, and at that time, you include the seller entity. 

Now, what the seller ID freezer, which is part of the object generator, does is it takes a query and checks if the type of the query is a long type. Then it checks if the query is a parameter type or a parameter query. After that, it goes down and verifies if the name is seller ID. If it is, it returns the seller ID; if not, it returns an empty value.

I can't create this, so to summarize again, the seller ID freezer is a generator that only produces something when the argument parameter's name is seller ID. Otherwise, it returns I don't know. If we look again at where the seller ID is used, it appears like we're just using a function, but in reality, we see the effect of that function returning an object generator being passed to the customizer. 

Next, in addition to the generator, a processor is also needed. For example, if there is a property defined with a setter, meaning it is set using a setter rather than through the constructor, then we use a processor instead of a generator. The generator is responsible for calling the constructor, so it does not call the setter. Therefore, the role of calling such a setter is handled by the processor.

So, let's take a quick look at the parameters. The generator receives the career context, while the processor receives a value as the second parameter. This means that it processes a value that has already been created somewhere. And it doesn't return anything. Next, the customizer takes in a generator and returns a different generator, as well as taking in a processor and returning a different processor. However, it can be a bit tricky because the generator also inherits from the customizer, and the processor inherits from the customizer as well. This might seem a bit odd, but it’s a structure created for ease of use. What this means is that the resolution context is designed to receive a customizer through the apply customizer. However, if it weren't for this structure, after creating a generator, I wouldn't be able to apply this generator.

We need to create one more customization. They say it's ten minutes before the deadline, which is quite a problem. To enhance usability, I made the object generator and object processor inherit from customization. Since we don't have much time, I'll skip over the boring details. Now, we can apply the customizer we created using the customization interface or annotation. However, I want to emphasize again that since the object generator and object processor inherit from customization, we can directly customize the generator as needed. I know it might not make much sense, but I'll move on because we're short on time. Using these features, we can extend AutoPaz to reflect our business rules. Earlier, I mentioned that later...

If we look at the auto domain source that was mentioned, the auto domain source is not provided by Auto Param. We create it using Auto Param. First, the auto source annotation is vertical, which means we are declaring that we will use the functionality of the auto source exactly as it is. Next, we will configure additional extended functionalities. Besides the features that the auto source has, I will extend it with new functionalities. 

Now, how does the auto domain source configuration type look? It uses a custom annotation, and with that, we use the three generators you see: PhoneNumberGenerator, PriceGenerator, and TTIGenerator. We are extending the functionality of the auto source using these generators. Let’s take a look at the PhoneNumberGenerator among these three. The PhoneNumberGenerator is also an object.

When implementing a generator and looking at the content, the type is a string, and it creates parameters that do not satisfy the rules of the query. However, the parameters can be created arbitrarily, but the parameters that do meet the rules will always generate characters according to the specifications of a mobile phone number. At that time, when getting the parameter name, it is not a primitive type but an object string. The parameter can be retrieved, but it may also not be present. This is due to the Java specification; in the past, Java did not provide parameter names using reflection. It started providing them after a long time. You need to include the option shown above to obtain parameter names. In the past, it was said that this was done to reduce binary size and for security issues, but now it has been realized that this is not very effective.

So, we need to include parameter options, but most of you here probably don't need to worry about that. This is because when you use the Spring Boot plugin, it automatically adds those parameter options for you. If you try to use reflection without Spring Boot, you won't be able to get the parameter names. Instead, you'll get names like arg0, arg1, and so on. However, if you use the Spring Boot plugin, you will always be able to obtain the correct parameter names.

Next, there is an annotation called Abbreviation. I'm getting a bit tangled up here because we are short on time. Now, this is related to the @Autowired class. Why is this necessary? If you don't have it, and you remove that line and run the test, you will encounter an error. What kind of error, you ask? It is called a multiple computing parameter error.

So, there are several entities trying to resolve parameters, and they are competing with each other to resolve them. The competition is between the Spring Extension testing tool and the parameterized test parameters. One is the parameter that uses auto-sourcing, and the other is the parameters provided by Spring Boot testing. They are competing over the same parameter. You might think it would be nice if the tools could manage this automatically, but that's not the case. Both AutoParam and Spring Boot tests rely on my unit, but they are completely unaware of each other. As a result, even if AutoParam does not want to compete with Spring Boot, it cannot avoid the competition because it is completely unaware of its existence.

There is no number, so we need to specify it. By using the @EnableAutoConfiguration annotation in the AutoConfig, if we designate the @Autowired annotation, the AutoSource will only create instances until it encounters the @Autowired annotation. If we look back at the example, we see that the items with @Autowired are placed below. This means that AutoSource starts creating instances from the top, and when it meets the @Autowired annotation, it decides not to create from that point onward. Consequently, since the three annotations are no longer handled by AutoSource, the Spring extension can create them. Fortunately, we are almost done. Today, I have simplified the explanation of the features I use in my actual work as much as possible to make it easier to understand.

In addition to that, it provides various features. For example, below, there are tools that support Kotlin, as well as Lombok and Mockito. Although it wasn't introduced today, there is also an instance property writer to support objects that have setters. I think it would be best not to use it if possible, but in cases where you have to use hidden fields, like when using JPA, there are times when you need it. In such cases, we provide an instance field writer that can be initialized using fields. That's all. We have exactly finished. Now, let's have a Q&A session. Also, regarding the book, I haven't been able to manage it because I've been too busy, so for those who ask questions, I will definitely give you a book. Ah, yes, I really enjoyed your lecture. I have a question that came up while you were presenting. In the object container, does null also exist?

I mentioned that it is treated as a value, but does that mean that the completely empty value cannot be handled, or what is the difference between null and an empty value? There are cases where we want to specify a null parameter when setting parameters. In this case, the auto parameter cannot be defined because it was not created. However, there are situations where we cannot even create null. For instance, if it is a type I don't know or a type I have never seen before. In such cases, it returns MT. If it returns MT, the container that MT represents cannot return any object type because null is used when something is supposed to be present. Therefore, unwrapping cannot occur. When unwrapping is not possible, it means that it cannot be handled. It indicates that I cannot create a core.

You're expressing it, right? Yes, please come a bit faster. Here, I have a book I want to have. Next questioner, yes, I think you were first. Thank you. You defined the exceptions due to unique constraints as false positives earlier, right? But, in a way, I thought that this was used to provide isolation testing by inserting random values for unique keys. Looking at this, I wonder if my intention was that while doing TDD, when a test doesn't roll back the database or when I clear the test, it takes too long, and I dislike that. Is that why you explained it that way, or was it just an example of usage? Ah, I mean, you're asking about my experience. When I do TDD, I don't roll back at all. Thank you. So, then...

Oh, well, the execution time is long, so maybe that's why you didn't roll back. Right? No, that's not it. I think I was concerned about the rollback because I was wondering if I was testing something incorrectly. But it's been so long that I'm not sure. Ah, I understand. Thank you. Please come quickly, as there are a few types of books you want. Also, I'll only take two people due to time constraints. Yes, I enjoyed the presentation. I may not know Auto Parangsae deeply, so I might feel this way, but it seems to provide most of the features offered by Instashiona Fixture Monkey. I would like to hear what aspects made you feel uncomfortable with the other tools, and from what perspective you think we can grasp the advantages of Auto Parangsae well. Yes, that's unfortunate. First of all...

What was it? Instancio, I had never heard of that before. I don't really know when that project started. When I looked it up in March 2021, I couldn't find it. There was something, but most of the projects had already been discontinued a few years prior, or they couldn't deploy version 1.0. As for Fixture Monkey, I don't know what the situation is now, but when I first started with AutoParam in 2021, there were two other contributors besides me. One of them was the person who started Fixture Monkey. At that time, I was told that my thoughts about Fixture Monkey were different from theirs. That person also mentioned they would contribute to AutoParam, and later, they created a plugin that could combine AutoParam and Fixture Monkey.

You mentioned that you created it, but I don't know much about the fixture monkey feature, so it's a bit difficult for me to explain the differences. Yes, I really enjoyed listening to it. Please come quickly so we can discuss the book again. Ah, it seems I still have some books left. Shall we take more questions? Time is up, but it's been a minute. Ah, the last question. It seems like someone over there has a question as well. Yes, to make testing easier, you structured the project. How did you use this project when testing? At first, during the initial test, since there were no auto parameters, I only tested using the influx feature. Once the auto parameter was released, I continued testing using it. The auto parameter itself... it seems there is another question over there.

It seems that you were present. Yes, yes, please come and take the book. The person who just asked a question, I listened well to your presentation. When you were initially structuring the project, you intended to incorporate the convenience provided by the ecosystem used in that shop into this project, correct? 

Yes, that's right. Then, during that work, you borrowed a lot from the core architecture and interfaces that were provided by the shop, right? 

Well, I did use some tools like AutoFixture, and I wanted to create something with similar functionalities. However, I'm not a contributor to AutoFixture, so I don't know much about its internal architecture. I created it to satisfy similar requirements on the surface, but I did not reference the architecture itself.

Thank you. Yes, please come and take the book with you. There is one book left, but what should we do? Well, I'll handle that. Ah, understood. Yes, thank you. Then I will conclude here. Yes, please give a round of applause to the presenter.

스프링캠프 2024 [Track 2] 5.AutoParams를 사용한 Spring Boot 응용프로그램 테스트 (이규원)

애플리케이션 서버 개발자들과 함께 가치있는 기술에 관한 정보과 경험을 `공유`하고, 참가한 사람들과 함께 `인연`을 만들고, 시끌벅적하게 즐길 수 있는 개발자들을 위한 '축제'를 목표로 하는 컨퍼런스입니다.

컨퍼런스에서 다루었던 내용들을 공유하는 채널입니다.

스프링캠프 2024 [Track 2] 5.AutoParams를 사용한 Spring Boot 응용프로그램 테스트 (이규원)

스프링캠프 2024 [Track 2] 5.AutoParams를 사용한 Spring Boot 응용프로그램 테스트 (이규원)

Scripts