CODEWITHSUNDEEP
c++googletest
ALIAS IZZ
ALIAS IZZ

Reputation: 21

writing a gtest for get function

this is my attempt to write gtest for this functions

actual code

Composite pattern UML

Im not sure how to approach this I'm trying find the most efficient way write gtest for these functions. I don't know if I'm calling the class and objects correctly in test and also I'm not sure if i need seters to be able to set string value and even that how to do it with multiple strings

#include "Datetime.h"
#include <string>
#include <vector>
using namespace std;
    
class Task
{
   private:
       Date date;
       Date deadline;
       Vector<Task*> subtasks;
       string tag;
       string description;
       int priority;
   public:
       DateTime get_date() {return date;}

       DateTime get_deadline() {return deadline;}

       Vector<Task*> get_subtask() {return subtasks;}

       string get_tag() {return tag;}

       string get_description() { return description;}

       int get_priority() {return priority;}

       void add_subtask(Vector<Task*> subtasks) {subtasks.push_back(subtasks);}

       void remove_subtask(Vector<Task*> subtasks) {subtasks.erase(tasks.begin() + i);}
};

Upvotes: 2

Views: 569

Answers (2)

NicholasM
NicholasM

Reputation: 4673

Your add_subtask and remove_subtask functions appear to have a confusing or incorrect signature. Maybe attempting to write tests for those would help?

Currently, the subtask-related signatures are:

class Task
{
   public:
       /* ... */

       Vector<Task*> get_subtask() {return subtasks;}

       void add_subtask(Vector<Task*> subtasks);  // Why multiple subtasks
       void remove_subtask(Vector<Task*> subtasks); // Impl was wrong
};

I think a signature like this might make more sense:

class Task
{
   public:
       /* ... */

       Vector<Task*> get_subtasks() const { return subtasks; }

       // Add one subtask.  Throws an exception if `subtask` is `this`.
       void add_subtask(Task* subtask);

       // Remove the indicated subtask, if it is present, and return
       // whether it was removed.
       bool remove_subtask(Task* subtask); 
};

After this, you could write tests like this:

TEST(TaskTest, SubtasksInitiallyEmpty) {
  // When a Task is initially constructed, it has no subtasks.
  Task t;
  const std::vector<Task*> subtasks = t.get_subtasks();
  EXPECT_TRUE(subtasks.empty());
}

TEST(TaskTest, AddSubtask) {
  // When `add_subtask` is called with a user-provided task,
  // the task’s subtasks contains that task.
  Task t;
  Task s;
  t.add_subtask(&s);

  const auto& subtasks = t.get_subtasks();
  ASSERT_EQ(subtasks.size(), 1);
  EXPECT_EQ(subtasks.front(), &s);
}

TEST(TaskTest, AddSelfAsSubtaskThrows) {
  // When `add_subtask` is called with `this` as an argument,
  // an exception is thrown.
  Task t;
  EXPECT_THROW(t.add_subtask(&t), std::runtime_error);
}

I didn’t include tests of remove_subtask, but they would have a similar structure.

Upvotes: 1

Mindstormer619
Mindstormer619

Reputation: 2806

This class doesn't actually seem to have any functionality -- it's basically a thing that holds data, also known as a data class. Ideally you shouldn't be writing tests for this, since it has no real behavior to speak of. Write tests for other classes and modules that make use of this class to do things. Your tests should be written to define expected behavior.

If, for some reason, you really absolutely need to write tests for this, all I can think of is a test that injects some value into each field using the setter for it, and retrieves the value back from the object using the getter and checks it.

Upvotes: 0

Related Questions