Return to Answer

Should we replicate the business logic in tests?

NO.

Ideally once the software has done, what is supposed to be tested, a test should just assert the actual state with the expected pre-determined state of the SUT.

As far as calculating pre-determined expected state is concerned ,a test's primary objective is to 'Verify' an expected state , not to 'Replicate' it.

In our team it is directly hard - coded in tests, copied over from Use Stories as captured in BDD( Cucumber) format as an example scenario with data which act as a communication tool between Business Analyst, Developer & tester.

But NO behind the scene operations in between the test like DB manipulations/ API calls except test data setups/cleanups before & after the test. No re-calculations of business logic inside tests. A big NO.

If we do that then we need tests for these tests also ,as then they are no longer tests anymore as they themselves implementing the functionality as the application code.

Should we replicate the business logic in tests?

NO.

Ideally once the software has done, what is supposed to be tested, a test should just assert the actual state with the expected pre-determined state of the SUT.

As far as calculating pre-determined expected state is concerned ,a test's primary objective is to 'Verify' an expected state , not to 'Replicate' it.

In our team it is directly hard - coded in tests, copied over from Use Stories as captured in BDD( Cucumber) format as an example scenario with data which act as a communication tool between Business Analyst, Developer & tester.

But NO behind the scene operations in between the test like DB manipulations/ API calls except test data setups/cleanups before & after the test. No re-calculations of business logic inside tests. A big NO.

If we do that then we need tests for these tests also ,as then they are no longer tests anymore as they themselves implementing the functionality same as the application code.

I am not sure about the specifics of the situation here so answering considering general scenario and specifics of my team.

Ideally once the software has done, what is supposed to be tested, a test should just assert the actual state with the expected pre-determined state of the SUT.

As far as calculating pre-determined expected state is concerned ,a test's primary objective is to 'Verify' an expected state , not to 'Replicate' it.

In our team it is directly hard - coded in tests, copied over from Use Stories as captured in BDD( Cucumber) format as an example scenario with data which act as a communication tool between Business Analyst, Developer & tester.

But NO behind the scene operations in between the test like DB manipulations/ API calls except test data setups/cleanups before & after the test. No re-calculations of business logic inside tests. A big NO.

If we do that then we need tests for these tests again....!

Should we replicate the business logic in tests?

NO.

Ideally once the software has done, what is supposed to be tested, a test should just assert the actual state with the expected pre-determined state of the SUT.

As far as calculating pre-determined expected state is concerned ,a test's primary objective is to 'Verify' an expected state , not to 'Replicate' it.

In our team it is directly hard - coded in tests, copied over from Use Stories as captured in BDD( Cucumber) format as an example scenario with data which act as a communication tool between Business Analyst, Developer & tester.

But NO behind the scene operations in between the test like DB manipulations/ API calls except test data setups/cleanups before & after the test. No re-calculations of business logic inside tests. A big NO.

If we do that then we need tests for these tests also ,as then they are no longer tests anymore as they themselves implementing the functionality as the application code.

I am not sure about the specifics of the situation here so answering considering general scenario and specifics of my team.

Ideally once the software has done, what is supposed to be tested, a test should just assert the actual state with the expected pre-determined state of the SUT.

As far as calculating pre-determined expected state is concerned ,a test's primary objective is to 'Verify' an expected state , not to 'Replicate' it.

In our team it is directly hard - coded in tests, copied over from Use Stories as captured in BDD( Cucumber) format which act as a communication tool between Business Analyst, Developer & tester.

But NO behind the scene operations in between the test like DB manipulations/ API calls except test data setups/cleanups before & after the test. No re-calculations of business logic inside tests. A big NO.

I am not sure about the specifics of the situation here so answering considering general scenario and specifics of my team.

Ideally once the software has done, what is supposed to be tested, a test should just assert the actual state with the expected pre-determined state of the SUT.

As far as calculating pre-determined expected state is concerned ,a test's primary objective is to 'Verify' an expected state , not to 'Replicate' it.

In our team it is directly hard - coded in tests, copied over from Use Stories as captured in BDD( Cucumber) format as an example scenario with data which act as a communication tool between Business Analyst, Developer & tester.

But NO behind the scene operations in between the test like DB manipulations/ API calls except test data setups/cleanups before & after the test. No re-calculations of business logic inside tests. A big NO.

If we do that then we need tests for these tests again....!