unit testing - Java: How to test void add, delete and change methods? -

i have few management classes used search methods, add, change , delete methods, print in table format method , write map file method. classes have container each attribute. lets there class x. class xmanagement, , container has objects of class x.

search() method returns object of x, first gathers id via input.

add() method gathers input data creation of object x, , last line of code adding object container.

change() method first searches object user wants change (via search() method), , gathers data , changes object via setter methods. calls write() method re-writing file.

delete() method searches object (via search()), , removes container, after calls write() method.

the write() method void. goes through container each object, , data appended parse-able string, written file.

here examples:

public class xmanagement {      protected hashtable<integer, x> xes = new hashtable<>();      public xmanagement(string filename) {         // constructor.         // loads input file, parses it.         // once parsed, objects of x class created.         // put container (xes).     }      protected x search() {         // both generic methods.         integer uuid = enterinteger("id");         return (x) find(uuid, xes);     }      public void add() {         integer uuid = uuid(xes); // generic method, generates uuid.hashcode()                                    // , checks duplicates.         string = enterstring("name");         date d = enterdate("start");         // ...............         x x = new x(uuid, a, d, etc);         xes.put(x.getid(), x);         write();     }      public void delete() {         x x = search();         xes.remove(x.getid(), x);         write();     }      public void change() {         x x = search();         string = enterstring("name");         x.seta(a);         date d = enterdate("start");         x.setd(d);         // .......................         write();     }      protected void write() {         file file = new file("x.txt");         bufferedwriter out = new bufferedwriter(new filewriter(file));         string curr = "";         (int id : xes.keyset()) {             curr += xes.get(id).geta() + "|" + xes.get(id).getd() + "|"; // etc         }         out.write(curr);         // there's, naturally, try/catch/finally here. sake of simplicity, left out here.     } } 

class x goes this:

public class x {     string a;     date d;     // etc     public x(string a, date d) {         this.a = a;         this.d = d;     }     // getters , setters. } 

it's lot more complicated that, tried keep simple here - i'll try figure out harder stuff when basics.

in management classes, methods , constructors have instances of other management classes input parameters, can call methods inside, because of them connected. let's y class has x attribute, , when create y object in ymanagement add() method, need able choose 1 available x objects xes, via search() method contained in xmanagement.

i decided keep simple now, if want, can tell me how approach testing i'd have instances of other management classes input.

---

how write detailed junit 5 test cases these methods?

sorry if made mistake somewhere in code, haven't copied written in here, generalizing stuff gets repeated in other management classes.

if have other suggestions, code itself, feel free write that.

these methods hard test because they're doing much. have input, output files, , data modifications.

let's @ method:

protected x search() {     // both generic methods.     integer uuid = enterinteger("id");     return (x) find(uuid, xes); } 

why call enterinteger when pass desired id method parameter? let client tell class id search for. search doing 1 thing: looking reference in map.

i think naming class x gives no information whatsoever it's for. i'd prefer gives me hint - better readability. abstract information out of code naming scheme. names matter. think harder one.

your xmanagement class looks simplistic in-memory database. have thought using allow use sql? maybe h2 better choice. if class interface based swap out implementation , clients not have change.

a better design partition responsibility out separate classes. example, data object accompanied interface-based persistence tier handle searches, updates, persistence, etc.

when find methods hard test, it's sign class needs redesigned. hard test same thing hard use clients.

i'd replace xmanagement class interface:

package persistence;  public interface repository<k, v> {     list<v> find();     v find(k id);     list<v> find(predicate<v> filter);      void save(v v);     void update(v v);     void delete(k id);     void delete(v v); } 

you'll have instance each 1 of shows, performances, tickets, users, etc.

package persistence;  public class showrepository implements repository<integer, show> {      // todo: you'll need constructor , map shows.      public list<show> find() {  // rest }     public show find(integer id) {  // rest }     public list<show> find(predicate<show> filter) {  // rest }     public void save(show v) {  // rest }     public void update(show v) {  // rest }     public void delete(integer id) {  // rest }     public void delete(show v) {  // rest }     } 

much better x, in opinion.

if write class using interface there won't console interaction in classes. needs passed in callers.

you can create separate concrete implementations in-memory cache, relational or nosql database each implement interface.