If your organisation uses the Apache v2 licensed Elasticsearch or Kibana in its projects or products, it must now assume that it is at risk one way or another. It can upgrade to version 7.11 of these projects, thereby accepting the terms of SSPL and potentially also being required to release the code for its entire stack (a great deal of which it will not have the copyright over and will be unable to release, thereby potentially being in violation of SSPL). It can remain on version 7.10, but then it will no longer receive future updates, including important security fixes, thereby taking on another sort of risk.
I look upto many persons in the industry who have achieved big milestones. One of them is Chris. His talk and post -https://quii.dev/The_Tests_Talk, will provide you with a tonne of information regarding TDD. If you are into GO, you should definitely check out Chris's book - https://github.com/quii/learn-go-with-tests.
I mean how many of you stick with this test driven development practice consistently?
I have been doing this for a while now. Practically, saves me a tonne of time and am able to ship software confidently.
Can you describe the practical benefit?
Say, a change is executed on one section of the (enterprise level)application. You missed addressing an associated section. This is easily identified as your test will FAIL. When the number of feature increases, the complexity of the application increases. Tests guide you. They help you to ship faster, as you don't need to manually test the whole application again. In manual testing, there are chances of missing out few cases. If it's automated, such cases are all executed. Moreover, in TDD - you only write code which is necessary to complete the feature. Personally, tests act as a (guided)document for the application.
Do you happen to rewrite the tests completely while doing the implementation?
Yes, if the current tests doesn't align with the requirements.
When does this approach work for you and when did it fail you?
WORK - I wouldn't call it a silver bullet. But I am really grateful/happy to be a developer following TDD. As the codebase increases, when new developers are brought in - TESTS is one of the metrics which helps me ship software.
NOT WORK - a simple contact only based form(i.e. a fixed requirement having a name, email, textarea field and an upload file option), I rather test it manually than spend time writing tests
The benefit of TDD is that the code you end up with will actually be testable. Just keeping in mind that you have to write a test for your code, changes how you write it.
As a bad example, imagine having a 1000 line function that just does everything you needed for the new feature... Good luck testing that afterwards.
> Just keeping in mind that you have to write a test for your code, changes how you write it.
Which is often enough to ensure the code is testable.
Generally, I'll write some tests sort of alongside, or soon after (like, a couple hours or a day) to not lose the initial thought process. Going back to code days/weeks later and trying to 'test' it when it wasn't conceived of as testable is tough.
Thanks for your perspective. Did it take a lot of time to develop the required discipline? I mean defining the interface for a single function is different from defining a set of functions in the context of a test. May i ask: what is your problem domain / field of work?
Did it take a lot of time to develop the required discipline?
I wouldn't say lot of time. If you get a good mentor, it isn't a steep learning curve. Moreover, I program using a framework, it has lot of helper functions.
May i ask: what is your problem domain / field of work?
I develop SAAS apps and complex HA web applications/API. I am web developer - PHP(Laravel to be exact).
cannot agree more.
i've worked for a year on a fast evolving software and we had to refactor things a lot. TDD helped me to refactor in confidence and without regressions.
Now i can't live without tests!
