unit testing - Java Selenium close browser after assertTrue -

i have code many classes.
there class creates driver -

public class driverdelegate {      private string baseurl = "somelink";     private webdriver driver;     private webdriverwait wait;      driverdelegate(string url) {         system.setproperty("webdriver.chrome.driver", "${directory}");         driver = new chromedriver();         driver.get(baseurl + url);         driver.manage().window().maximize();         driver.manage().timeouts().implicitlywait(5, timeunit.seconds);         wait = new webdriverwait(driver, 5);     }      public webdriver getdriver() {         return driver;     } 

i create new driver every test. , of lines ones containing asserttrue this-

public class userinterfacetests extends basetest{       @test     public void headerclicker() throws java.lang.exception {          //startup         driverdelegate driverdelegate = new driverdelegate("url");         webdriver driver = driverdelegate.getdriver();          //some random asserttrue         asserttrue("test(headerclicker) - nosuchelementexception click", testhelper.headerclicker(schedule, driver));          //i hope not neccessary put helper classes testhelper or basetest 

now launch tests class called startup -

public class startup{     @test     public void headerclicker() throws exception{ userinterfacetests ui = new userinterfacetests(); ui.headerclicker();} 

my question here how close browser after asserttrue fails. things @aftertest, @aftersuite etc not work because other methods can not use same driver used in test.
ideas?

ok there few things want touch on here. first off, @shutdown -h correct in comment shouldn't programmatically creating test classes , running @test methods yourself. let test running framework handle (e.g. testng, junit, etc).

to point of actual question, though, want pre-test , post-test methods handle behavior occurs before , / or after actual test method. these work, though, need let test framework handle running of tests. mentioned @aftertest , @aftersuite not being correct use case, though not reason specified (entirely). @aftertest in testng executed once after test methods in classes inside of <test> node specified in suite. @aftersuite executed once after test methods in entire suite. looking @aftermethod annotation.

example:

public class footest {      private driverdelegate driver;      @beforemethod     public void setup() {         try {             driver = new driverdelegate("url");         } catch (exception ignore) { }     }      @aftermethod     public void teardown() {         try {             driver.quit();         } catch (exception ignore) { }         driver = null;     }      @test     public void foo() {         // test stuff     } } 

in above code, when testng runs test class, each method annotated @test in class have corresponding @beforemethod execution initializes driver , @aftermethod closes driver if test fails. couple of points make type of setup testng:

(1) testng not create separate instances of test class if save state on class object cannot run test methods in parallel within class since have multiple methods trying create new drivers , save them same variable, corrupting state of other tests running. can run parallel mode of per class (e.g. have 5 threads, each running separate test class @ same time).

(2) why did wrap @beforemethod , @aftermethod bodies in try-catch block? because testng takes fail on configuration method exceptions , can cause other tests haven't run yet skipped need deal code possibly fail. wrapping creating , closing of web driver can ignore error , continue on running other tests. if driver fails created, instance, driver variable null , @test method fail others might succeed. ideally, should have logging of exception can investigate why driver failed created, instance.

also, if need use driver in many test classes, can make base class creation of driver along closing of after each method , have test classes extend that. if have class method annotated @test on it, run @beforemethod methods on test class , on of super classes well. there guaranteed ordering of methods between classes (though not if have multiple @beforemethod methods in same class).

public abstract class {     @beforemethod     public void setupa() { } }  public class b extends {     @beforemethod     public void setupb() { }      @test     public void foo() { } } 

in above, when foo run, have run first setupa , setupb. after methods work in same way, in reverse order.