Skip to main content

You are not doing your tests 'appropriately', and this is part of your issue.

thereThere is no need for the 'supplier'. The supplier is an instance field, and, it's an extra level of abstraction that is unnecessary. JUnit has concepts at play that allows it to run tests in parallel. Having instance fields that are not part of the before/after sytsemsystem can lead to problems.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circulatcircular construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.

You are not doing your tests 'appropriately', and this is part of your issue.

there is no need for the 'supplier'. The supplier is an instance field, and, it's an extra level of abstraction that is unnecessary. JUnit has concepts at play that allows it to run tests in parallel. Having instance fields that are not part of the before/after sytsem can lead to problems.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circulat construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.

You are not doing your tests 'appropriately', and this is part of your issue.

There is no need for the 'supplier'. The supplier is an instance field, and it's an extra level of abstraction that is unnecessary. JUnit has concepts at play that allows it to run tests in parallel. Having instance fields that are not part of the before/after system can lead to problems.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circular construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.

deleted 190 characters in body
Source Link
rolfl
  • 97.5k
  • 17
  • 218
  • 418

You are not doing your tests 'appropriately', and this is part of your issue.

JUnit tests should each have a new instance of the players. You should not reuse one player for all of them. In other words, instance variables/fields are not ideal. JUnit has a concept of Before and After methods that are called before, and after each and every test.

Youa re using those before and after methods just fine, but, there is no need for the 'supplier'. The supplier is anotheran instance field, and, it's an extra level of abstraction that is unnecessary. JUnit has concepts at play that allows it to run tests in parallel. Having instance fields that are not part of the before/after sytsem can lead to problems.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circulat construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.

You are not doing your tests 'appropriately', and this is part of your issue.

JUnit tests should each have a new instance of the players. You should not reuse one player for all of them. In other words, instance variables/fields are not ideal. JUnit has a concept of Before and After methods that are called before, and after each and every test.

Youa re using those before and after methods just fine, but, there is no need for the 'supplier'. The supplier is another instance field, and, it's an extra level of abstraction that is unnecessary.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circulat construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.

You are not doing your tests 'appropriately', and this is part of your issue.

there is no need for the 'supplier'. The supplier is an instance field, and, it's an extra level of abstraction that is unnecessary. JUnit has concepts at play that allows it to run tests in parallel. Having instance fields that are not part of the before/after sytsem can lead to problems.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circulat construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.

Source Link
rolfl
  • 97.5k
  • 17
  • 218
  • 418

You are not doing your tests 'appropriately', and this is part of your issue.

JUnit tests should each have a new instance of the players. You should not reuse one player for all of them. In other words, instance variables/fields are not ideal. JUnit has a concept of Before and After methods that are called before, and after each and every test.

Youa re using those before and after methods just fine, but, there is no need for the 'supplier'. The supplier is another instance field, and, it's an extra level of abstraction that is unnecessary.

Instead of the supplier, you should have an abstract method, and your @Before method should be changed:

protected abstract PlayerAction supplyPlayerAction();

@Before
final public void beforePlayerActionAbstractTest() {
    playerAction = supplyPlayerAction();
}

Then, in your concrete class, instead of trying to beat the circulat construction logic, all you need to do is to implement the concrete method supplyPlayerAction() like:

protected PlayerAction supplyPlayerAction() {
    return new AttackMonsterAction(0, 0, Player.createFromConfiguration(PLAYER_CONFIGURATION, "Opponent"))
}

This way the @Before things happen in the predictable order, etc.

In your pro/con terminology, you cannot implement a concrete class of the abstract class, without implementing the abstract method. The method is called in the @Begin in the Super Class, and the Super Class @Begins are called before the concrete class.

This is the way it should be done.