Refactor unit tests?

When we work with legacy code and need to do changes, we first write tests on the current behavior. That way we can implement new changes with confidence. We can even refactor the code.

Legacy code is often bad code, and after some refactoring the code may be simpler, easier to test. Since the refactor has been validated by the tests should we also refactor the tests if we can make them simpler/clearer or keep them as they were written?

Go to Source
Author: JayZ

REST API Testing best strategy

I’m currently developing a personal project using Django REST + React and as it grows more complex, I want to add unit testing to ensure that changes don’t affect previous functionality. However, I’m not sure exactly what to test for. Should I simply test the responses from the API endpoints, should I try random input to check if it’s validated properly, should I try getting access or changing data that belong to a different user? What is the best strategy to ensure that a REST API is both stable and secure through testing?

Go to Source
Author: Antonis Karvelas

Clean Architecture use case testing

Use case interactors in the Clean Architecture consists of the application specific business rules.

Clean Architecture diagram

Interactors uses the Data Access Interface to fetch the required data from the data access layer.
Basically I see two approaches to test these interactors.

  • Using test doubles rather than the actual data access layer
  • Using the real data access layer (e.g. sql database, webservice)

I personally prefer the first approach and test the data access layer seperately.
The interactor tests uses the Data Access Interface with the test doubles and the entities in the inner circle.
An architectural boundary is crossed in both approaches.

Is the first test approach considered as Integration Testing with a narrower scope or is it just Unit Testing?

Go to Source
Author: Stefan

Is the self-shunt pattern the same as stubbing in TDD?

I am reading the book TDD by Example and one of the patterns demonstrated was the self-shunt pattern.

Basically, if I am not mistaken, if I have a test like this:

test("list of users should receive a new user"), () => {
  const user = new User()
  const listOfUsers = new ListOfUsers()
  listOfUsers.insert(user)
}

Then, the only way to know if listOfUsers actually received the user, is to stub it, correct?

class ListOfUsersStub {
  constructor () {
    this.users = []
  }

  insert (user) {
    this.users.push(user)
    return this.users
  }
}

then I can test it so:

test("list of users should receive a new user"), () => {
  const user = new User()
  const listOfUsers = new ListOfUsers()
  const result = listOfUsers.insert(user)
  expect(result.users).toContain(user)
}

Is this the same as the self shunt pattern? Or am I missing something?

Thanks

Go to Source
Author: kibe

How to test C++ code when using C functions

I wrote a c++ class, this class uses the c function library written by a third party.

extern "C" {
#include "nats/nats.h"
}

class NatsConnection {
  public:
  void Connect() {
    natsConnection_Connect(&natsConnection_, natsOptions_);
    natsConnection_SubscribeSync(&natsSubscription_, natsConnection_,
                                 configuration_.subject.c_str());
    // some other c++ code.
  }
}

The above class uses functions imported from c: natsConnection_Connect, natsConnection_SubscribeSync.

Now I need to write a unit test to cover some other c++ code, I am using gtest, I know how to mock a C++ class, but once I use the C code I don’t know how to start.

how do i write the test? Is there has a best practice?

Go to Source
Author: MengHan Yu