2017-02-21 3 views
0

Мне нужно написать модульные тесты для моих методов. У меня проблемы, потому что я новичок в JUnit. Мне нужно написать тест для метода getter созданного типа объекта. Тип объекта - UnitInfo, и мне нужно написать тест для методаТест JUnit для метода getter типа пользовательского объекта

@Override 
public UnitInfo getInfo() { 
    return info; 
} 

в здании класса. Я поместил свой класс здания, класс UnitInfo и класс buildingTest в код ниже. Любая помощь приветствуется. Класс

package main.model.facility; 

import java.util.List; 

public class UnitInfo { 
    private int capacity; 
    private String name; 
    private int idNumber; 
    private List<String> details; 

    public int getCapacity() { 
     return capacity; 
    } 

    public void setCapacity(int capacity) { 
     this.capacity = capacity; 
    } 

    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 

    public int getIdNumber() { 
     return idNumber; 
    } 

    public void setIdNumber(int idNumber) { 
     this.idNumber = idNumber; 
    } 

    public List<String> getDetails() { 
     return details; 
    } 

    public void setDetails(List<String> details) { 
     this.details = details; 
    } 

    public void addDetail(String detail) { 
     details.add(detail); 
    } 

    public void removeDetail(String detail) { 
     details.remove(detail); 
    } 

} 

Строительство:

package main.model.facility; 

    import java.util.List; 

    public class Building extends Facility { 

     private List<IFacility<UnitInfo>> subunits; 
     private UnitInfo info; 
     private ScheduleManager schedule; 

     @Override 
     public UnitInfo getInfo() { 
      return info; 
     } 

     @Override 
     public ScheduleManager getScheduleManager() { 
      return schedule; 
     } 

     @Override 
     public List<IFacility<UnitInfo>> listFacilities() { 
      return subunits; 
     } 

     @Override 
     public int requestAvailableCapacity() { 
      int availableCapacity = 0; 
      for (IFacility<UnitInfo> subunit : subunits){ 
       availableCapacity += subunit.requestAvailableCapacity(); 
      } 
      return availableCapacity; 
     } 

    } 

Junit

public class BuildingTest { 
    Building defaultBuilding = new Building(); 
    ScheduleManager defaultSchedule = new ScheduleManager(); 

    @Before 
    public void setUp() throws Exception { 
    } 

    @After 
    public void tearDown() throws Exception { 
    } 

    @Test 
    public void testGetInfo() { //this is the test I need to write 
     Building b = defaultBuilding; 
     assertEquals(b.getInfo(), null); 

    } 

@Test 
public void testGetScheduleManager() { 
    Building a = defaultBuilding; 
    assertEquals(a.getScheduleManager(), null); 
} 
+0

http://stackoverflow.com/a/21355383/1878022 этот ответ поможет вам – VedX

+0

Только для записи: с точки зрения «хорошего дизайна»: попытайтесь сделать так много ваших полей ** final ** насколько это возможно. Кажется соблазнительным разрешить их изменить с помощью сеттеров; но очень часто, что на самом деле имеет ** не ** значение. Таким образом, лучше отступить и тщательно решить, какая информация должна быть обязательной ** при создании объекта и не подлежит изменению. Это ** также ** уменьшает количество кода, который вы должны проверить! – GhostCat

ответ

1

Не стройте свой Building на уровне класса, создайте его внутри модульного тестирования, так что каждый тест имеет свой собственный Building для работы. Таким образом, они не будут мешать друг другу.

Ваш тест кажется прекрасным на данный момент, вы не инициализируете info при создании нового Building, так что info имеет значение NULL, и вы утверждаете это в своем модульном тесте. Вы также можете использовать assertNull(b.getInfo());.

@Test 
public void testGetInfo() { //this is the test I need to write 
    Building b = new Building() 
    assertEquals(b.getInfo(), null); 
} 

Если вы сделали инициализацию info к чему-то еще, скажем info = new UnitInfo(), то вы могли бы изменить свой тест на:

@Test 
public void testGetInfo() { //this is the test I need to write 
    Building b = new Building() 
    assertNotNull(b.getInfo()); 
} 

Как насчет того, при создании нового Building вы инициализирован info и установить некоторые полей.

info = new UnitInfo(); 
info.setIdNumber(100); 
info.setName("Some Unit Info"); 

Затем в тестовом модуле можно утверждать, что поля были установлены:

@Test 
public void testGetInfo() { //this is the test I need to write 
    Building b = new Building() 
    assertNotNull(b.getInfo()); 
    assertEquals(b.getInfo().getIdNumber(), 100); 
    assertEquals(b.getInfo().getName(), "Some Unit Info"); 
} 

Идея с юнит-тесты, чтобы осуществить свой код; вызовите свои методы, а затем утвердите, что результаты - это то, что вы ожидаете. Как только у вас будет хорошая база модульных тестов для всего кода, вы можете быть уверены в его изменении, потому что знаете, что ваши тесты скажут вам, когда вы что-то сломаете.

Держите ваши тесты маленькими и простыми, не делайте слишком много. Просто выполните свою настройку, вызовите метод и убедитесь, что результаты верны. Затем напишите новый тест и сделайте что-нибудь еще. Не пишите тесты, которые делают 5 разных вещей.

Смежные вопросы