New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate methods of restarting applications for faster TDD #32686
Comments
Thanks for the proposal. When practicing TTD on a Spring app, I find that I make minimal use of full-blown integration tests when in the red, green, refactor loop. Much of the time, I'll be working on an individual unit running unit tests that have no dependency on Spring at all. These tests are very quick. For the less common occasions when I'm working on an area of integration between multiple units, I find sliced tests useful as they allow me to focus the integration test on only a small number units. These tests can also be quick although not as quick as the unit tests. The slowest part is often starting Docker containers via Testcontainers, but this can be improved with container reuse. The longer-running |
I was hoping we don't get into this discussion 😁 OK let me try.
Now one could argue against the above by saying none of the above is true for a bad integration test. To which my reply would be if someone writes a bad integration test, they would also write bad unit tests too. So "everything equal", still the above hold true. Or at the very least you cannot make any conclusion about which type of test is better. I also skip "the risk of testing mocks instead of production code" in unit tests to not open another blackhole-like discussion 🙂 (I also fully appreciate the significance of unit test in places where the scope of the test coverage is low. No doubt!) |
Of course, writing code is not easy. But When it's done using Test driven development methods it will look easier and totally hassle-free. Actually, the solution here is Integration tests. Also, FYI I've also made an article on Test driven development; please visit it if any of our curious readers want to know more interesting facts about Test Driven Development. |
This is a feature-request.
Any non-trivial (web + any datastore) spring boot application would have a 10s seconds startup time, most of them around 1 minute, and some extreme cases reach to 2 minutes. This is obviously a huge blocker for any flavor of test driven development work-style. Anything beyond a few seconds to run the test and get a feedback on my changes makes the TDD style impossible to employ. I'm sure many smart people already thought and pointed out this but the fact that no official solution or recommended pattern is known (to the best of my knowledge) is surprising to me.
Here's the use case: I would like to employ a TDD approach; one line of test code, run the test, one line of production code, run the test, repeat with minimal waiting time for Spring context to start.
Solutions
One solution is to keep the context light. I'm pretty sure there's a limit to this and very quickly it hits the ceiling in terms of startup performance optimization.
A better solution is to start the application once (in the IDE or in command line using Gradle for example) and start coding. Having the DevTools, production codes are reloaded automatically very quickly and test code can be executed as many times as needed considering that now the we don't have to wait for the context to start. I've created a proof of concept here.
Proposal (Draft)
SpringBootTestApplication
AnnotationHow to use it: Add it to a (non-test) class in the
test
folder which effectively makes the class a spring boot application and use the class as the configuration class inSpringBootTest
annotation wherever the context is needed.What it does: when added to a class, creates a very thin Spring Boot application in which it creates the main application (or a slightly different version of it with respect to main application configurations) as a bean.
Vision for the feature
Notes
I'd be happy to work on the feature, but for sure needs help with some of the internal code of Spring Boot Test module.
Thanks.
The text was updated successfully, but these errors were encountered: