Tag: testing

Test void methods with Autowired classes

I am a begginer in Spring and I need to write test for this class if it calls methods:

class ClassOne {

    @Autowired
    AutowiredClass a1;

    @Autowired
    AutowiredClass a2;

    void methodOne() {
        a1.method1();    
    }

    void methodTwo() {
        a2.method2();
    }
}

I’ve tried to write test, but failed, got NPE:

class ClassOneTest {

    @Autowired
    ClassOneInterface c1i;

    @Test
    public void testMethod1() {
        c1i.methodOne();  // <- NPE appears here..
        Mockito.verify(ClassOne.class, Mockito.times(1));
    }
}

Halp..

Would be great to successfully test void methods.

Solution:

You can verify that using a unit test:

@RunWith(MockitoJUnitRunner.class)
public class MyLauncherTest {

    @InjectMocks
    private ClassOne c1 = new ClassOne();

    @Mock
    private AutowiredClass a1;

    @Mock
    private AutowiredClass a2;

    @Test
    public void methodOne() {
        c1.methodOne(); // call the not mocked method
        Mockito.verify(a1).method1(); //verify if the a1.method() is called inside the methodOne
    }
}

Why is the SUN_LEN macro dereferencing NULL without an error?

I’m currently looking at a clang sanitizer error that tells me that I’m dereferencing a nullptr during the runtime of my program. Looking at the source of the problem, I got to the SUN_LEN macro in sys/un.h on Arch Linux which looks like this:

/* Structure describing the address of an AF_LOCAL (aka AF_UNIX) socket.  */
struct sockaddr_un
  {
    __SOCKADDR_COMMON (sun_);
    char sun_path[108];     /* Path name.  */
  };


#ifdef __USE_MISC
# include <string.h>        /* For prototype of `strlen'.  */

/* Evaluate to actual length of the `sockaddr_un' structure.  */
//                                                      vvv This is NULL?
# define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)        \
              + strlen ((ptr)->sun_path))
#endif

It seems this macro is always trying to access NULL so the fault seems to be there. But I highly doubt this is a bug as this macro is used everywhere and seems to work fine (beside the sanitizer warning), so I’m wondering why this is not crashing and why it’s there in the first place?

Solution:

The macro

#define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)        \
              + strlen ((ptr)->sun_path))

does not dereference a NULL pointer.

So let’s take look at the internal parts of the macro:

(((struct sockaddr_un *) 0)->sun_path)

This is not deferencering, this is casting NULL pointer to a struct sockaddr_un pointer.
The ->sun_path is there for the pointer arithmetic:

struct sockaddr_un *so = NULL;
char *offset = so->sun_path + strlen(ptr->sun_path);

The last part is the cast to size_t

size_t size = (size_t) offset;

which converts the address store in offset in a numerical size_t value.

In this case it is basically doing 

size_t val = offsetof(struct sockaddr_un, sun_path) +
    strlen(ptr->sun_path) * sizeof *ptr->sun_path;

What I cannot tell you is why this macro is defined in that way, the guys
implementing this socket library might have good reasons for that instead of
using offsetof, which internal is also a macro. A gcc -E for this offsetof
shows me:

 size_t y = 
# 46 "a.c" 3 4
           __builtin_offsetof (
# 46 "a.c"
           struct sockaddr_un
# 46 "a.c" 3 4
           , 
# 46 "a.c"
           sun_path
# 46 "a.c" 3 4
           ) 
# 46 "a.c"

Junit 4 Testing coverage

I am unable to cover next method:

protected void dealDamage(int damage, String damageType) {
    this.setDamageDealt(damage);
    this.setDamageDealtType(damageType);
}

My test looks like this:

@Test
@Parameters({"30, physical"})
public void dealDamage(int damage, String damageType) throws Exception {
    this.creature.setDamageDealt(damage);
    this.creature.setDamageDealtType(damageType);
    assertEquals(this.creature.getDamageDealt(), 30);
    assertEquals(this.creature.getDamageDealtType(), "physical");
}

Test return success, but method is not covered at all. Where could be my mistake? Do I miss something?

Solution:

The problem is you are not calling the method that you want to unit test, i.e. dealDamage()