Daily standups cost average-sized product engineering teams 6-figure sums every year, so we sure as heck need to make them count. Here's how I think we do it.

This article explores Agile testing, including shift-left testing, test automation, and collaboration between developers and QA.

Using the structured framework, product prioritization can effectively meet the needs of customers and address their pain points.

Refocusing from output to income. The feature factory fate is not inevitable; there is hope to avoid becoming a mere cog in the machinery. Learn how!

Scaling teams of site reliability engineers comes with many challenges. Here, explore the challenges of scaling and review a successful scaling framework.

Delve into the crucial concept of an internal DevSecOps platform, what it is (IDSP), and why businesses need it.

Discover the key principles that shape solid software design and explore real-world examples to strengthen your development skills.

During the 54th Hands-on Agile meetup, David Pereira shared tried and tested practices to avoid the feature factory fate.

This guide is your roadmap to mastering Event Storming for architects, analysts, and curious minds, offering insights into unraveling the secrets of complex systems.

Generative AI has evolved into powerful content generators thanks to DL algorithms. However, to get more accurate results, different cycles and iterations can be used.

Product managers need a collaborative team culture and effective methodologies like Agile. Clear vision, trust, feedback, and diversity are vital for success.

In this article, I explore the pitfalls of ‘The Illusion of Velocity’ in Agile contexts, peeling back the layers of traditional metrics as leadership tools.

This is the third of three articles analyzing the 183 anti-patterns from the upcoming Scrum Anti-Patterns Guide book. Let's dive in!

This article discusses security risks in application integration and strategies for protecting digital assets while keeping up with technology trends.

Learn what OpenTelemetry is and how it supports vendor neutrality for DevOps and SREs to monitor and observe microservices in the cloud.

Learn how to write automated tests in order to ensure that given Spring features are used properly and discover generic advice on how to improve unit tests.

Appropriate EA framework selection is critical for Enterprise Architects based on the Organization's needs and goals.

CXOs guide to the software development lifecycle (SDLC) processes, models, and best practices — to lead effectively and efficiently.

Discover the top 10 DevOps trends of 2023, shaping the future of software development and IT operations. Stay ahead in the DevOps game!

The article presents a compiled list of unit tests naming strategy that one could follow for naming their unit tests. The article is intended to be a quick reference instead of going through multiple great pages such as following. That said, to know greater details, please feel free access one of these pages listed below and know for yourself. What are some popular naming conventions for unit tests? Unit Tests Naming Best Practices GivenWhenThen Technique How to Unit Test Stream Pipelines and Lambdas CI/CD Pipeline Testing Following are 7 popular unit tests naming conventions that are found to be used by majority of developers and compiled from above pages: MethodName_StateUnderTest_ExpectedBehavior: There are arguments against this strategy that if method names change as part of code refactoring than test name like this should also change or it becomes difficult to comprehend at a later stage. Following are some of the example: isAdult_AgeLessThan18_False withdrawMoney_InvalidAccount_ExceptionThrown admitStudent_MissingMandatoryFields_FailToAdmit MethodName_ExpectedBehavior_StateUnderTest: Slightly tweaked from above, but a section of developers also recommend using this naming technique. This technique also has the disadvantage that if method names get changed, it becomes difficult to comprehend at a later stage. Following is how tests in first example would read like if named using this technique: isAdult_False_AgeLessThan18 withdrawMoney_ThrowsException_IfAccountIsInvalid admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing test[Feature being tested]: This one makes it easy to read the test as the feature to be tested is written as part of test name. Although, there are arguments that the “test” prefix is redundant. However, some sections of developer love to use this technique. Following is how the above tests would read like if named using this technique: testIsNotAnAdultIfAgeLessThan18 testFailToWithdrawMoneyIfAccountIsInvalid testStudentIsNotAdmittedIfMandatoryFieldsAreMissing Feature to be tested: Many suggest that it is better to simply write the feature to be tested because one is anyway using annotations to identify method as test methods. It is also recommended for the reason that it makes unit tests as an alternate form of documentation and avoids code smells. Following is how tests in first example would read like if named using this technique: IsNotAnAdultIfAgeLessThan18 FailToWithdrawMoneyIfAccountIsInvalid StudentIsNotAdmittedIfMandatoryFieldsAreMissing Should_ExpectedBehavior_When_StateUnderTest: This technique is also used by many as it makes it easy to read the tests. Following is how tests in first example would read like if named using this technique: Should_ThrowException_When_AgeLessThan18 Should_FailToWithdrawMoney_ForInvalidAccount Should_FailToAdmit_IfMandatoryFieldsAreMissing When_StateUnderTest_Expect_ExpectedBehavior: Following is how tests in first example would read like if named using this technique: When_AgeLessThan18_Expect_isAdultAsFalse When_InvalidAccount_Expect_WithdrawMoneyToFail When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior: This approach is based on a naming convention developed as part of Behavior-Driven Development (BDD). The idea is to break down the tests into three part such that one could come up with preconditions, state under test and expected behavior to be written in the above format. Following is how tests in first example would read like if named using this technique: Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail My personal favorite is naming unit tests based on the writing features of the class under test. It helps me to make sure that a class follows single responsibility. It also aids a great deal in code refactoring. Related: How to Integrate Cucumber for Spring Boot Integration Tests