Testing with Spring Framework 4.3, JUnit 5, and Beyond

welcome to the talk on testing with spring 4.3 jaded 5 and beyond first up my name is Sam Brannan I'm a spring and Java consultant at a company called Swift mind and I've been a Java developer for over 17 years so quite a while and a course spring committer since 2007 when I first rewrote springs integration testing support so it's bringing test context memory call the annotation driven stuff and I've managed it since then I'm also a lead for this spring user group in Switzerland and Zurich I'm a trainer and a conference speaker no surprise there and last but not least more recently since last October I've been a corps commander for J unit 5 so so if mine just quickly about my company experts in spring Enterprise Java in general focusing on spring spring portfolio Jayne at 5 now as you might imagine Java EE in general we basically just do software architecture code reviews these kinds of things and you can find us online and Zurich Switzerland but obviously we can travel as well so the agenda today start off and just show you give you a brief intro to an app that I use for some of the demos called spring events then we'll talk about the new features in spring for 3 it just came out recently and then we'll talk about brand new Jane 2 5 how far we've gotten the features you can expect their extensibility and all these kinds of things and then last but not least we'll look at the support for Jane 5 in testing coming with spring five dot o then at the end we'll have a Q&A session if we have some time there if you have a question during the middle just feel free to raise your hand so first up show of hands who writes tests everyone okay who doesn't write tests anyone brave enough to claim that No ok who writes unit tests unit tests and when I say unit tests I mean not using spring not using embedded database stuff like that yeah and who uses who writes integration tests and keep your hands up if you write those with spring yeah ok that's good all right who uses on something like Spock testing framework a few people tests ng okay few hands and J unit yeah okay anyone write any test with J unit three just out of curiosity still nobody alright nobody I enjoyed stuff like that Jana for like up to 412 yeah most people okay good good to know so there's some spring of in SAP you can check it out its online it's just an example I put together demonstrating a couple of different technologies with spring and spring boot it is a spring move powered web app right now I just recently upgraded it a few days ago to spring boot 1.4 the latest and greatest Spring Framework 5 milestone 1 which is just released and Ju new 5 milestone 2 which was also just released so if you want to see kind of the latest technologies working together in terms of testing I have to assume this is the most advanced app you'll find at least this week on the Internet so basically it has a simple POJO domain model with events transactional service layer using spring data JPA for the repository layer spring we see time leaf and a rest presentation layer and all this stuff is is tested in addition also has spring security and as I mentioned the recent upgrade to Jane at 5 so if you interested in checking that out you can check out my github account here that's Brandon spring events if you want to download it and play with it later on actually just saw a tweet this morning somebody found it useful and upgraded their own app to spring boot 1.4 test and Jana 5 and they said it was successful so that's good news so next up first main category here what's new in Spring Framework 4.3 starting off to some of the the odds and the ends as a base requirement now you have to have at least some Jana 412 otherwise it won't work you'll get an exception telling you that otherwise so there shouldn't be much of an issue just a straightforward upgrade to Jana 412 that's if you're using the spring test contracts framework right so this integration testing support from a spring other stuff doesn't X require an upgrade for Janet another minor future there is support for what we call primary transaction managers and data sources so if you had annotated for example some being with that primary and you had multiple transaction managers or multiple data sources the spring testing framework would not work the same as your production code and take the primary one if you didn't specify otherwise next up who's ever heard of them at SQL for executing execute it's a few people there okay so you can basically have the spring testing framework run some SQL scripts before your tests or after your tests for setting up the database you're cleaning up and these things can now be used as meta annotations for example if you want to create some custom composed annotations with attribute overrides that's now supported and the same is actually true for most at repeatable annotation so if you're familiar with Java 8 you never pupil annotation sanitation declared multiple times on a method or class or something like that and basically this works for most repeatable annotations across course spring now so you can create custom composed annotations with those next up reflection tests you till some of you might have seen that for setting private fields and things like that in your pojos and your controllers and stuff like that and as we spring for 3 this will now automatically unwrap any proxies that were created for those things so when you're setting and getting probably people to unwrap the foxy you might ask how do they how could that happen well if you have a meeting the application context where you created a mock like with Makita or something like that and you want to teach questions such details it's that stuff stuff in it if it got um wrapped in a proxy this would then unwrap it if you had a transactional being there that got wrapped with AOP behind a proxies that unwrapped it for you next up a bit more low-level in terms of extending the spring test context framework and for through you have some new features first up the get test context method and the test context manager is now public if you don't know what the test context manager is you probably don't care but if you're integrating with spring this makes it more reusable and was a necessary change in order to support jn5 next up we have a new context customizer API and those things can be configured or created via context customizer Factory basically this can be placed potentially the need for creating your own custom context loader so if you have some integration code where you're creating their application context on your own with spring this might be a better alternative for you and what it does is basically allows you to customize the application context after the mean definitions have been loaded so after Spring knows about all the beans it supposed to create but before the context is actually refreshed so before it started so you can add other beans for example if you saw the at Mach being support from spring boot that's actually how that works and these things registered globally using the spring factories mechanism so kind of like the service loader mechanism yes and exactly so this is what enables a lot of the new spring boots test magic in spring boot 1.4 so there's stuff like at mock bean it actually uses this feature and if you want to do something similar you could of course do that on your home some new features we saw in the the keynote yesterday if you're tired of typing spring Jane at for class runner can't remember the name of it there's now an alias called spring runner so you can just very easily type in that run with spring runner class and we'll see later on that that aligns with the Jaina 5 support which is called the spring extension another feature that was kind of driven by boot here is the ability to omit the at context configuration annotation completely if spring can detect default xml files or groovy scripts or add configuration classes and in the case of spring boot test 1.4 that does some some other magic there so spring boot will actually um use class bot scanning to find your configuration class that's annotated with that spring boot application so basically these just less to type in as a feature here another important feature a lot of people who have very large test suites might have several different sets of configuration for our application contexts and those all get loaded in cached in memory so you might run into memory problems so what we added in 4-3 is support for a bounded cache so the application context those that are loaded for your tests they're now in a cache with a maximum size of 32 as the default number and that um basically uses an LRU least recently use evasion policy so the last or the application context it was least recently used will get evicted if another one is loaded in and that should wear comb fine in most cases but if you don't like that if you want to make it smaller or if you want to make it bigger hopefully you don't want to make it bigger because that's usually a bad code smell that you have too many different configuration sets but if you wanted to change that you can set that via the spring test context cache max size JVM or system property so let's take a look at that in action the where are we let's see so I have an example here with sorry with JUnit 4 is that can people see that yep because this is the run with spring Jade for class runner we could run this class and see how long it takes so took about 3 seconds there and the first thing I was saying is you could drop this rink Jade for class runner and just switch to the spring runner and that should still continue to work on the other thing we said is that at context configuration right here it's empty um you might want to configure it with some other classes if you're just got something like that but by default it's going to look for a configuration class in the same test class if I static nested configuration class which we have here so we can see that now in spring for we can just delete that that declaration and it's hopefully going to work just the same right so just a bit less typing and that works just fine now in terms of this context caching I have a test suite this is using Jane at 5 we'll get to that later but let's just run it and kind of see what happens here in the console in terms of logging so it's going to take a little while had several of an application how next when I take about 20 seconds potentially and after this runs we should see lots of um context um cash statistics so we see stuff like this that the context cache the size is 3 the max size is 32 right that was the default and we had a hit counter 91 and a miss count of 3 so that's that's good just not know much turning going on there with the defaults and I think if we looked to the very bottom we'd see a kata sizes is still 3 and if we wanted to switch that up to change it just show you that that actually works hopefully I can do that easily by change in the run configuration and specifying this okay so I don't have that let me grab this property here property name and I should be able to set in something like a dash D and they set that equal to 2 and then we should see that it wouldn't be bounded by 2 with a max size so if you had taken up a lot of memory and you wanted to reduce that you should be able to configure that pretty easily so we see already the max size is 2 for all of these and at the end obviously you should have slight changes there at the bottom so the miss count was still 3 hit count 93 but now the size is to it in the max sizes too so if you have any issues with a caching you can configure that now okay now in terms of preparing for the future just kind of change some things in the core testing framework to support things like we call testing traits basically springing testament Asians can now be declared on on interfaces right and this combines nicely with Java eight default methods so if you're not on actually who is on Java 8 a curiosity ok about half of you right so uh maybe you heard with job eight you can have default methods and interfaces that means you can have implementation right you can have behavior with your interfaces and this allows you to do things like traits that come from other programming languages so you can have some basic testing functionality in an interface and implement that in different test classes so this combines nicely with with Jana five as well another thing in this direction transactional test methods no longer have to to be public you might not care at the moment but as you move to Jana 5j and five you don't have to have public classes or public methods so you'll probably just get used to not typing public anymore so it's best if spring also kind of works in the same way there and that also holds for testing G the same is also true for at before transaction and at after transaction methods supported by Springs transactional testing support there's no longer need to be public and in addition those can also be declared on default methods and interfaces so you could have like a transactional test rate that does some stuff before your transactional tests and after them and you could basically implement that testing trade in several test classes another option would of course be to have an abstract base class but you might find that these kind of testing traits see you needs better now we'll switch to some improvements in the web testing scenarios so for spring MVC tests we have the mock MVC that we can use there if we have response headers that have multiple values we can now set expectations on those that wasn't possible previously and that's via a new string values method plural there with an S and the result matches so you might find that useful another feature now is the form data around request content for example if you have a post spring MVC test when L parse that from the post and use it to populate request parameters in case your controller is actually using those as cross parameters another feature that was requested is support for custom HTTP verbs so spring MVC test naturally supports things like get post delete these kinds of things but maybe using some kind of custom verbs like WebDAV and that's also now supported with a new request method on the Builder that takes a string for the the method name the HTTP method name and if you're using the HTML unit integration support with some you see tests if you ran into any issues with with cookies they've been a couple of improvements there so hopefully we resolve those if not then just raise an issue and we will look into it another cool feature when spring you see tests now you can now assert which handler method was invoked with a balk like feature you could have done in the past just based on the name but now there's a new method call assertion in and the result matters and you can assert so the controller method that was actually invoked to serve the response under the hood this uses on NBC URI components builder which is part of spring MVC now part of the heart of the test and I'll point that out an example here so let's assume we have a home page and we have a home controller that populates some data to be displayed in that in the agent ID HTML so let's say we have for example a home controller class and it has a show home page method that has an at request mapping for get to slash so if we're using spring MVC test we can now say perform the get request and now we're going to expect that the handler method call was on this home controller and in this method so this on thing here this is a static method that's imported from this MVC or I components builder so you can now be very explicit and type safe in terms of how you're verifying these things right so even if you refactor the test would refactor along with it next up JSON prefixes whose ever heard of a json prefix anyone no one okay so um well we have support for it now we can strip it off in some you see test basically you would want to use a prefix to prohibit what's called JSON hijacking so if someone um some malicious hacker tried to have a script tag that loaded your JSON content with a get request and then view the contents of some sensitive data that would be JSON hijacking and to avoid that several companies for example like Google they prefix their JSON content return from their rest web services which is something that doesn't compile with JSON right so here it might be prefix with something like and an enigma and n if that's the case then you can tell us putting BC to strip that off so this is just standard Springer BC to a JSON rest service here and we're saying we want to get the pin number out and verify the 23:4 but please strip off the enigma prefix there so that's supported in Spring Framework 4.3 so that was a server-side right when you're testing your own controllers your ID or your own rest endpoints and now we'll talk a bit about some new features for client-side right when using the rest template to talk to a remote web service and you want to mock that out so that is the mock rest service server and you can now set expectations for the form data and any requests that you're sending via the the rest template and that's in this new form data method we see here on the request mattress you can also specify expectation count so I think this is pretty cool pretty useful feature here and also a nice API for this basically what you do is you pass in an expected count to the expects method on the mock and those are static methods we see several of them here things like once right so this is similar to what you see and in mojito or some other framework like that right I expect this thing to be called once or many times or just twice or maybe somewhere between two and five times right things like that and you can then at the end verify I mean reset if you want to right and so then the verify is going to obviously throw an exception if your expected count expectation is not met another feature here you can specify whether ordering should be ignored so you specify multiple things that should be invoked with this rest template or multiple requests and you can set for example the ignore expect order to true if you want that to be ignored on the Builder you just invoke another method in between so normally with the Builder you would say something like mock rest service server bind to your rest template there and then build and then the new feature here just say ignore expected order so it doesn't matter the order in which those things occur so that's it for spring four three now we're going to dive into J unit five so who had heard of Jane of five before this conference six people seven people have not too many okay who has actually um tried it out anyone few people okay alright so hopefully this will give you an idea of what to expect in the upcoming Jane at five and and where the hopefully the world is going in terms of testing on the JVM so the impetus for changed let's start there Jaina for was released a decade ago so quite a long time ago a lot has changed since then particularly testing needs have have matured people don't like just unit tests people write integration tests system tests into end tests and they do that all with with Jana so one thing I tell a lot of people it's it's unfortunate that Jane it is called Jana because half the time now we're not writing unit tests but the word unit is in there so don't get confused right you can use Jana to write any kinds of tests basically but in addition expectations have grown so people expect more features that make integration testing easier in their testing family that was written for unit testing right so we need some new extension models for third parties to come in and provide additional support in terms of modularity with J unit four I say kind of jokingly big Malamud in terms of the the internals but basically there's just the one big monolithic Jaina jar that means use it as a developer use that as an extension writer use that as the IDE or the build tool everybody uses the same jar and that kind of makes it difficult for junior itself as a framework to evolve another thing test discovery and execution those are tightly coupled so again this is all coming back to kinda the idea that there's only the one Jaina jar and it's not really that easy to extend or for IDs to to integrate that well with it and the extensibility so something like a framework like mojito or spring wanted to integrate with Janet there's a lot of room for improvement there in terms of Jayne at four and let's not forget right so what's happened more recently job eight things like land expressions method references streams and these kind of things these are things that Jane at four can't support cos Dana for is based on Believe It or Not Java 5 which is quite old these days the runner so if you used spring right you've seen the spring shader for class runner or maybe you've seen the makita runner stuff like that that's the basic extension model in Indiana for from the starts and shading at 4'o it's very powerful in fact you can do anything but you have to do everything if you're the one writing this and another big downside it's physically impossible to combine runners you can say run with this runner and and that's it so case in point parameterize the very property from jane itself the spring runner also very popular over the years people said i want to have parametrized spring tests and that was just physically impossible so room for improvement there next up to address some of these issues the jana team introduced rules and if you read this I would say rules are meant to be broken we know that and Jana rules are also meant to be broken and actually we're in fact kind of broken all along the way so in Jana 4:7 their support for method level rules and Jana for nine support form class level rules the downside is you have to implement them separately they're great for simple use cases they can even be combined so it's a big step up from from the runners but you cant use the single rule or method level and class level callbacks which might not mean so much to you but it means a lot more to an integrator like spring trying to provide additional support to you as a tester plus there's zero support for what I call instance level callbacks which something like mojito or spring needs in order to inject dependencies into your test case in point here I'm not sure if you're familiar with it but a year ago we released support for rules in springs testing support but to get that to work I had to write two rules I had to write a spring class rule and it's being method rule and kind of write some hacks to get them to work together and that's obviously not the nicest for spring as an integrator but also not the nicest for you because you have to define two things and copy and paste this code everywhere so in order to address these issues we started the Geneva lambda crowdfunding campaign lambda because of lambda expressions and and new things coming in in Java 8 and I was initiated by a guy named Johannes link and Mark Philip in Germany and then later joined by two other Germans Matthias Meredith and Stephan duck-billed and I joined later on as well that ran from last July through last October if you here last year you heard some of the announcements about joining in and contributing for this and then winded up raising almost 54 thousand euros from 474 individuals and companies and four companies donated six weeks of developer time including pivotal who's the organizer of this conference so thank you if you donate it I know there's some people here who did and some companies and again we see pivotal listed up here at twice once it's a cash donation and once there's a donation for supporting a developer so we got pretty far with that we started off with a kickoff meeting last October and we see the team here we had some some big names and Industry coming in and helping us decide on the direction we needed to go so obviously we had our own ideas as developers we figured it's probably a good idea to ask some IDE developers and some build tools so we had um people there from a developer from eclipse to developer from IntelliJ I developed her from from Gradle people from Gotham pivotal Oliver Gierke some of you might reckon in there I'm also in the picture as well so had a good time lots of good discussions a lot of prototyping in that first initial week and then we began real work with just a core 5 developers so we actually delivered a prototype tagged in a 5 story last December we released an alpha back in February and then we worked long and hard between in February and July and we released the first milestone early last month then as it often goes with projects like that right after that Mouse and release we discovered some some bugs so we released a milestone - just went out a few weeks ago and that's what spring 5 now now builds on so that's pretty stable has what all the core features you need and we'll dive into that in a minute in terms of we're going from from here we hope to get some additional milestones out this year and hopefully a release candidate in the fall and then maybe potentially a five died oh gee a release by the end of this year I mentioned we had the crowdfunding campaign unfortunately all that money is gone now lots of hard work put in so now the team is also down to three individuals working only in their free time so I can't really promise we'll make it by the end of the year but we will do our our best to achieve that so what is Jayne at five we've already kind of mentioned why we want to have it why we want a new Jayne it first up in contrast Jana for Jana five is modular it's also very extensible in fact the spring integration I wrote spring integration with Jana 3j2 for Jane or five in testing G and the easiest integration so far was the integration with with Jane at five so it's much easier for anyone to integrate into J and it now we like to think it's modern you can be the judge of that yourselves but one very important feature is it's both forward and backward compatible at the same time which might sound a bit tricky we have actually achieved that so basically we have this idea of the JUnit platform and the Jaina platform supports Jana 3-8 Jana for and Jana v all at the same time and it also can support any other kind of frameworks now so that's a very big plus so new testing frameworks can be run an additional in addition with the existing Jana forced infrastructure with Jane at five so you have lots of opportunities there to combine things to get the platform running the easiest way right now is to actually use Jana for the J and for running infrastructure there at run with and then Jane at platform as a class and then you can basically set up a testing suite that you can launch Jana for tests with Jana five tests may be something like Kotlin or spec C or some other test engines and we'll get to that more in a minute so another big thing about jane at five is that it's not just j units kind of the program model the way you kind of think about jane or four so jana five is actually an accommodation or three things this combination of what we call the platform itself Jupiter and and vintage so the platform we assigned that of 1.8 version and that's the foundation for launching testing frameworks on the JVM and that's not limited to Jane it right that's any anything on the JVM any programming language runs of the JVM it should work with the Jaina platform for that there are launcher and test engine api's and we'll talk about in a second there's also a console launcher for running from the command line we have written our own plug-in for Gradle our own plugin for from maven so you can actually have stuff running in the build even though Gradle and maven don't support that officially yet on their own we hope to hand that off and IDE support that's also in the works Jane at Jupiter so Jana Jupiter five-o is actually the new programming model for it Jane to five but it's also the new extension model for Jane of five so that's what you're gonna be using the most as a developer and then Jana vintage we had some different ideas about what to what to call it basically it's all the old stuff the legacy or what will eventually be legacy so everything that runs now with with Jana for we call that Jane advantage and we have on a test engine that integrates all of your existing code existing tests into the JUnit platform so this launcher API if you're interested in writing some kind of build support or ID support or maybe some kind of your own standalone application to run your tests you can use that but primarily it's gonna be used by the IDs and build tools to actually launch the platform or the entire framework and it's a central API for discovering and executing tests via one or more engines so anjana for we had runners and in January have engines if you want to think about them kind of as an analogy to tell the Jaina launcher what to run there's a launcher discovery requests and that supports things like selectors and filters selectors would be things like select its class like this package select this method by its unique ID or something like that these are things I want to run and I want to filter stuff out I want to don't want to run things that aren't tagged with this things like that and those engines can provide feedback via the test execution listener API so if you're familiar with spring with the test context framework don't get confused the spring also has a test execution listener interface called the same thing but they're not the same so this test engine again this is kind of like what a runner is in jail for except that we don't expect that many people to write their own engines since Jana 5 as much more extensible we assume most people will just use the Jupiter engine so the jane at 5 programming central model and provide extensions but you can write a test engine so if you want to support something completely different maybe something like based on XML files maybe something like cucumber maybe something different like Scala or groovy or something like that you could write your own engine and in fact people have already begun doing that when guys already started support for his own fragment called spec see that runs Java groovy and Scala and from IntelliJ when the developers there is developing a spec for for Kotlin testing framework so these test engines they're responsible for discovering and executing tests but limited to a particular programming model and that's key and that's actually the way the Jain in five or the platform can support Jane of five Jane at four and Jane you three at the same time in the same test run that's because we have different annotations so the classes look different so the engines know okay this is a junior a four test annotation so I can run it if it's tainted for and the Jane of five size says this is the annotations for Jane to five Jupiter so I know how to run that one and then there are no collisions in terms of what's in your class path everything the way these things are registered that happens automatically with the standard Java service loader mechanism so if you have the jar in the class path if you have the Jupiter one or the vintage one then the platform will just automatically find those and you'll have support for that test engine automatically so friggin for Jane of five there's a Jupiter test engine for Jane at four and Jane three there's the vintage test engine and that would also count for stuff like like Spock or anything like that right that's based on Jane to four and you can of course implement your own now picture is worth a thousand words right so here we see we have the the platform big and red here at the bottom and the IDS and build tools are gonna see that side of it right so then they're not gonna focus on the program models they don't care they just want to be able to say launch tests based on these classes based on these paths these XML files these patterns stuff like that and in the top you see you can have different frameworks that are tied in to the platform here we have Jupiter against as the Jane to five program model of vintage supporting Jane of four three eight and here as an example any third-party test engine as I mentioned this the spec C framework already has its own support for Jane at five so in terms of the internals what that looks like inside if you're writing a test against a into five the only thing you actually care about is the API like the annotations and the assertions and stuff like that you don't care about the internals or about this launcher or these test engines or any of these other things so your code just depends on that and then this Jane Jupiter engine in the middle it supports the programming model there and then communicates with the launcher so this all hooks in together and then the same is true for for any of these engines we see inside talking about integration with build tools so we have the Maven surefire provider here the Gradle plug-in down here this one's using the console launcher and here we have this Jana platform runner which is that uh what I showed you earlier with that J at run with jaqen platform so in terms of the extension model we start with the extension mama said the the programming model just because it kind of helps to have a good idea of what kind of extensions there are and you can kind of understand how the features work with the extensions so to start with there is an extension API is an interface but it's just a marker interface and that makes it easier for us to have them all registered with the annotations this is located in the origin at Jupiter API extension package so one thing we've done to make sure there are no issues with the classpath right instead of just doing everything in origin or like was done in jana for everything in jupiter has this jupiter name there in the middle so that alleviates some of the problems one might run into with a class path and different versions so this package contains all of the extension api's they're all interfaces you can implement one or you can implement all of them I think there's something like 13 right now and the spring extension implements something like eight of them so you implement as many as you need tying into the functionality that Janie supports another thing is you can register multiple the same time and we talked to the support at extend with so again Jane it has the runner and Jane Jane for has the runner chained to five has extensions Jana for you to said run with something Jane you five you say at extend with and you can register one thing like the spring extension where you could register something like Experian extension some kind of parametrized extension maketo extension all those things at the same time and there's no problems there right so that's a big improvement over over Jane at four and where you can declare this you can declare this attic student annotation on an interface so Graham will get like a testing trait you're developing on your test class itself or on a test method those are the ways you can declare extensions and another feature you can also declare it as a meta annotation I'll show example of that later third-party extensions would would often want to do that or need to do that so you can also do for yourself to reduce the amount of configuration in your testing suite so in terms of these api's we have tests like lifecycle callbacks as we can see here at the top we have before all and these things wrap right so we have before all at the end and after all this is analogous to before class and after class if you're familiar with that from jana for then inside we have it before each and after each they wrapped around this is like so at before and after kind of in in Gen 4 but these are the extension points for that and then we have a lower level that we don't have with Jana 4 so extensions can actually do something immediately before the test method is executed or immediately afterwards so again for example the spring extension implements all all six of these another feature we have is what's known as um conditional test execution that can be applied at the container layer a level or the test execution level one thing about Jana 5 is we try not to focus too much just on on Java on Java classes and methods so when you see container in the general case it means the class and when you see test execution the general case that means a NAT test method next up test instance post processor has anyone ever heard of a bean post processor and spring few people so this is inspired by that actually a lot of the features in JUnit 4 are actually Jayne if I were inspired by 5 frameworks like spring so this is kind of like a bean post processor but it's the test instance post processor so an extension can do things like read fields or inject field something like maketo might do that and spring for example uses this next up parameter resolver anybody ever used spring MVC yeah at request mapping methods methods yeah and you know you can add all sorts of parameters like the request the response your domain model this kind of stuff so that also heavily inspired Jana 5 we have a parameter resolver which is similar to the support there in spring MVC and that allows for things like dependency injection for constructors and and method last but not least we have a test execution exception handler that's if you wanted to write your own kind of extension for logging exceptions that were thrown or maybe your own expected exception extension you could do that so that would be invoked right after the test text method is executed and you'd have access to the exception that was thrown if any so now we have an idea kind of about the extensibility let's dive into the programming model in a whirlwind tour ok so everything you need as a developer is an org Janet Jupiter API package basically all you need we have support annotations in there I'll support for meta annotations we have assertions and assumptions custom display names and I'll be showing some examples of these things visibility I mentioned that before Jain and five is no longer stubborn or as stubborn as dandruff or wasn't in some ways you don't have to make your classes public you don't have to make your test methods public as long as they're not private Jain it will find them and execute them after all Jain it uses reflection anyway so it's it's no big deal they're tagging who has ever used something like test groups in testing G few people who's ever used something like the category support in Dana for a few people heard of that so one idea is um you have groups of tests you have some things that are a long-running right you know slow test or some fast tests maybe you want to say these are my unit tests use my integration tests these are my CI my continuous integration server tests and you want to just tag them right so that's supported in Jane of five and basically uh in the future all I des and all build tools will allow you to configure which tags you want to run so you could have multiple different configurations on your build server like running the slow ones the fast ones etc conditional test execution talked briefly about that before dependency injection as well for constructors and methods also support for lambda expressions and method references and things like assertions and in timeouts and also dynamic tests we'll get to in a second support for interface interface default methods nested tests classes that's a definitely a new kind of way of writing tests and we'll see talk about that in a minute as well and last but not least these dynamic tests which will help more with an example so that's just kind of an overview of what there is in terms of the annotations surprised we have an app test annotation we couldn't come up with anything better than that so it's called the same as in Jana 4 and pretty much anywhere else what difference here is this does not have any attributes or parameters it accepts it doesn't accept the timeout or an expected exception because we expect to do that in a different way with lambdas and stuff on Java 8 also at test Factory is for dynamic tests at the for all or not after all again these are like at before class and not after class in gender for at before each and not after each you can put these on methods you want to execute it before your test method or after analogous to a nap before method or an at after method in jane at 4 next up we have this at display name that's we're providing a custom display name at tag internet before that's how you declare it and at disabled is like at ignore from Janet for also accepting some information there for whites disabled and not nested if you want to have these nested classes in terms of assertions we have the org Jana for sorry or Jane Jupiter API assertions class someone analogous to the assert class from Jane for we provide there a limited set of course urchins basically mapping on to what you're already familiar with from from Jane to for things like assert equals assert not and all assert same these kind of things assert or a equals we have to work for all those common cases but we have some new things more powerful so we have stuff like the cert throws and expect throws so that you can assert that an exception is thrown by a given block of code that you provide via a lambda expression so this is what you do instead of having the expected exception rule or the expected exception at the test level stuff like that I'm also recently just added this in a week ago support for asserting timeouts on blocks of code also provided via a lambda expression so this is kind of weird this builds upon and goes a step further than what you had in Jane for another cool feature is anyone ever been annoyed if you write multiple assertions in a method and some you change some code and you're on the test and the first one fails and then you go fixer stuff and you want us again and then the second assert fails and then you pick some stuff and you go back and the third is anyone have been annoyed by that yeah has anyone ever heard of soft assertions from a certain J maybe okay so that's something that sergej does a different way to do it what we have is assert all and then we allow you to provide all of the things you want to assert as lambda expressions and Jane will invoke all those catch all the exceptions and they collect all the exceptions so it's really nice if you're checking something maybe like you have your equals method maybe only depends on the ID of something but you have like a person has a first name last name street address all these kind of things and you want to search all those and see all the failures together you can do that nicely with assert all next up the one thing you'll notice if you're trying to migrate from Jane 4 to Gen 5 all the messages the error message you can provide to an assertion they all now come at the end as the last parameter so you have like a certain spectral and then the message and another thing that's cool with lambdas you see this in logging frameworks as well lots of places these days familiar with suppliers so this is a functional interface supplier string is just some little thing that provides a string so your error message and you can use that for lazy failure message evaluation so that means um if you have a two string method or some some kind of error message you're building up that it takes a long time there's no reason to execute that if there's no failure so this allows the testing member to evaluate that lazily basically speeding up your tests or your test suite which is always a good thing and if you don't like all this stuff or if you don't need this or you prefer something like assert J or ham press then that's totally supported those things throw assertion areas and other exceptions so there's absolutely no problem using those instead of the assertions from Janet next up assumptions basically building on the concepts from jana for there this is in the assumptions class a limited set of course on Asians again for this is where aborting tests mid-flight so on a test condition would have a test skipped before the test is executed and an assumption that fails is going to abort a test mid-flight so the tests already started and there for some reason you decide you don't want to continue because this file is not there or this isn't available on this server or something like that so there's the standard support for things like this you're assumed true and assumed false and also supporting land expressions here with a boolean supplier instead of just a boolean you might have something that generates a boolean and again for the messages you can use a supplier string just like with the assertions another feature is that we have this assuming that so you're assuming that some assumption is true then execute this block of code which is a lambda expression so you might say assuming that I'm on the CI server then additionally run these assertions but otherwise continue so don't stop the test but just only run this condition least kind of it is you might think of that as a glorified if statement and if you prefer an if block then you could do that in addition so now I'll try to do some live coding here and what's my claim tests and assertions right so let's it's good for it so for starters as I mentioned things don't have to be public alright so you can have a test class and then you have a test method don't pick the or gain one because that's gonna make it Jane before right pick the or Jane at Jupiter API one and again this doesn't have to be public so oops that should be a perfectly legitimate test now in terms of IDE support Eclipse doesn't have any support built in yet for detecting and running the jo5 tests the latest version of IntelliJ does the latest beta versions 2016 . - so one thing you can do in the interim is a temporary work around my son strange we're going to use Jane at 4 to run Jane to 5 okay so run with and we have a Janet platform runner and I'm gonna add the public on why does the public has to be there because j-unit won't run the class if it's not public so just ignore these two lines ok they're not there in the future you won't ever need to type them but for right now in Eclipse that's the the one what he does so now I could you better run this and not too exciting didn't assert anything but it's there so there's our first test one thing you can see at the bottom that's slightly different we have this so this is a basically a test suite and then what happens is the platform finds all the engines the test engines and it runs all the tests for those so the test engine we're using the Jaina 5 programming model is Jana Jupiter so that's why we see that and then we see our test class and then we see the test method and of course we should be able to fail something shouldn't be too exciting but that should work as well so there we have the failure right and double-clicking should jump right to it that's good so no problems there let's try an assertion how about assert true and let's say false so we want that to fail but now this exception can come into the message could come at the end right so the string message comes at the end that works and we see down here failure false now what if this was some kind of complex string we were generating and what we could do is we could create a land expression here on the fly and say complex I can type sorry complex message something like that so this is our lambda expression we're providing here right in here and if we run this then that gets evaluated lazily but again if this were true the benefit of that is this does not get evaluated unless the assertion fails right so that's how you can potentially speed up your test if you have I've seen tests where people actually end up checking stuff in the database to try to give more context now it's obviously gonna take more time and you don't want to contact the database every time you run an assertion right stuff like that some of those other things we're talking about assertions for exceptions so what if I want to assert that something throws an exception I can use this assert throws and I could say I expect maybe a runtime exception okay type sorry about that and then this would need to be a lambda expression so we have some potentially a block of code maybe like this the does some stuff let's assume we're calling something in our service layer that throws I have a hard time typing while standing new runtime exception okay now if we run this that should pass if we change this to just exception and that should fail we would hope right so here we have this error down here that says expected type thrown to be runtime exception but was telling exception and you could of course provide some kind of error message here as well oops or this one sorry we have not added that support yet they ignore that okay in terms of timeouts that I'm not working uh-huh so let's ignore that for a second I don't have that that's in the m3 upcoming milestone so it's in a snapshot but I can show you an example of that in a demo that we have maybe where I can just add one so add timeout and then the way this works is with um durations so you can say like duration of amount which would be something like maybe you know 100 and the timeout should be temporal unit was that I working right yes sorry why is this not working the demo gods are not with me today well they don't want to waste our time I'll just show you in the user guide that's there for sure so we have this support for stuff like this you can say assert time out of milliseconds so 10 milliseconds and then something that may take longer or less and this one takes 100 milliseconds instead of 10 and that would throw an exception and you could have things that pass right if they if they don't take much time the one side we have what's called a lazy eye search than the timeouts is just gonna let the code run and then at the end if it took too long as you can throw the exception but that runs it in the same thread which you might want if you have some kind of framework using like thread locals for example something like spring for a transaction management uses thread locals whereas on the flip side if you wanted to use on a pre-emptive timeout and have this code executed in a separate thread we have a certain timeout preemptively they would launch that in a separate thread using an executor service and then end that task if it doesn't end on time so we have all that support ok test names names by default like you familiar with um Java JUnit for example right they default to the test class or the test method names and the characters are gonna of course be limited based on the Java syntax so when one featured from other things like Spock or other testing framers is you can have names with spaces and special characters and stuff like that so if you want to use that you can use the at display name annotation can contain special characters even emoji which is a something most people find quite amusing dependency injection so this is where the extension model meets the program model because someone has to perform the appendage action but you can make use of the feature again there's this parameter resolver extension for that for constructors and and methods and test info if you knew about like test names stuff like that from jayne-ann 4 with chain 5 there's a test info you can have that injected injected into your actors you're at test methods you have before et cetera and you can get access to things like the custom display name the tags so she would have that the class the method etc and in the background if you wanted to yell to implement it there's a test info parameter resolver extension that does that for you you can also see the test reporter which is a way to add additional information to your your test report for particular tests the Mojito extension is an example we've written and we're in communication when we create a team that will eventually take that over and of course the spring extension performs dependency injection so for the display names you should be able to show that pretty quickly getting rid of this one the the name there before was just a first test right so if I wanted to say display a name my first test something like that and then run that will see down here right my first test shows up the downside is since the IDE doesn't know how to handle display names if you double click on that it's going to complain saying something like method my not found but in time that will be resolved of course and the other thing I wanted to show if I can have an emoji here I can just copy and add that in if I wanted to throw in the emoji and run the test then Wow see you can even have a mode unit yes surprisingly that's the only thing everybody claps for when I want to talk it I don't know what that says about our community but emojis are cool yeah the the current support in IntelliJ for some reason does not display the emoji so I don't know but in Eclipse if you want it like this it will display the emoji and also from the command line and your build reports you can see emoji on your CI server and stuff like that the test info I'm not going to show well I can show there really quickly so in terms of this dependency injection you can have the test info injected and for the sake of time I'm just going to print that out you rerun the test and we should go to see in the console hopefully no what did I do they're not compiled because of this one yes it's no longer throwing a runtime exception we'll just ignore that so now we see in the console right so this is information right if you need that Tessa info has the emoji as well no tags were declared we could have done that and then you can access the test class the test method and other stuff like that so for reporting or if you need to do something conditionally based on that you can so tagging used to Claire um Act tag on a test interface class or method for example we see like this at tag fest fast and add tests this is a fast test by default all tags are basically ignored but if you say only run with these particularly included tags then fast would have to be declared as one of the tags for this run another option is to use meta annotations coming up with custom compose annotations so you can declare at tag as a meta annotation on your own annotation maybe we have something like this fast test that we want to reuse across our code base again this would not have been possible with Jana 4 because Jana 4 didn't allow things like at tests to be declared on annotations but like spring Jana five now allows us so here we're saying at tag fast and that test right that's like we had on the previous slide these two things here we've moved them to our own custom annotation and then we can just say at fast test on our methods right and you can also have other stuff you could even configure stuff like imagine Springs I'd SQL to run some scripts or at transactional all that kind of stuff so you could have like fast transactional tests pretty pretty cool options here conditional test execution again this is where the program model meets the extension model these two types the container level and the test level at disabled itself is an implementation of one of these are actually both of these combined and there's a disabled condition you can look up the source code for that if you want to kind of see how to write your own one of the really cool things and the reason the next statement eating our own dog food we didn't want to make at ignore like in jada 4 which is hard-coded in Bakke 10 we wanted to have this concept of conditional test execution so that's disabled two implements that but you can implement your own so you can write your own conditions for things like don't execute on the weekend things like that don't execute on the CI server the funniest I've seen have to share the story some guy wrote a blog and was like yeah we have this test it fails rather regularly and on Friday afternoons after 4:00 p.m. I don't want to run it because my boss make me stay and try to fix it so this is disabled on Friday afternoons and that you can write code like that that works I don't condone it but you see the magic so you can check the current time the current server time zone connected database all sorts of things like that and if you don't want to run things that are disabled one nice features you can deactivate via launch of launcher assistant property call Jane and conditions deactivate and that's a pattern document in the rapid way no how do you do that but for example if you didn't want to use this disable one you could just say or Jenna dot star and it'd be turned off or you could turn off your own so what you can do is maybe you have a bunch of test disabled over time and you want to see are they really still broken why they also still disabled you can run them all now and if none of them failed and just go back and delete the disabled annotation for example interface the vault methods I mentioned before like with spring kind of sense idea of testing traits test interfaces you can implement multiple of those at a time in terms of J in it five things that are supported there your app before each add after each methods can be on default methods so you can even have default test methods default test factory methods I left that out and at tag and you can also have a text in which so you can configure the extensions you want to use and then have that functionality brought in when you implement one of these so-called testing trades so you can check out the string tests and use a guide for example that nested task glasses something you may have needed before or looked for and now supported and j25 and now enables logical hierarchical grouping of your test classes with shared initialization and States so it's not just like having static nested classes these are actual inner classes basically just this declare at nested on such an inner class and you can even combine these nested classes and testing traits or test interfaces so for example that I recommend you check out the testing a stack example in the user guide to see that in action dynamic tests one of the cooler cooler things or people find pretty cool if we think about conventional tests we would say there are static in the sense that they're their compiled in write you can look at the source code and say I have this at test method it's there I know it's going to run but sometimes you want to do things on dynamically or maybe programmatically so with junuh for there's a dynamic test that can register it at runtime provided as a lambda expression in a stream collection etc and that's I'm done within a method that's annotated with at test Factory so these are somewhat analogous to parameterize tests the accepted parameterize tests are parameterized by an extension something external and for a dynamic test you can parameterize them but you parameterize them your own programmatically within your own code so I will see if I can show that in an example here I don't think I've ever live coded one of these I'll do my best to do it right from the start stream of dynamic test I'm going to work it's like a piling no well of course not it's not returning anything it yeah so we should be something like I don't know let's go with a be like that so we have a stream of strings and then for each of those you want to map each them onto a dynamic test I'm gonna that is a unique feature of Eclipse dynamic tests so now I should be able to say something like dynamic test and then give it a name and I could say the the tests for each of these this is a string coming in string maps to and then I could say the display name is something like test : maybe plus the string and then the executable could be whatever I want it to be I could be just some kind of assert true alright I can do anything fancy there for the moment I would much prefer to sit to do this what did I get wrong here stream of a beam a parameters and what's even going on here let's the stream then I would test map as Eclipse being mean to me yeah it's not come where's the end she'll be able to collect them all I'm not sure what's going on there okay demo God's not my favor dynamic tests we have some demos so I can just show you what that looks like here they see that dimension on there the map ended it to the dynamic test and then the code you want to run and you return the the stream of that and that will run all those tests dynamically just the return you're saying yeah but it's still I'm not sure that's not important so let's a move on sorry about that okay so what's missing the official build and ID integrations I mentioned before that's coming we have our own plugins IntelliJ ID 2016 a2 has base support so you can actually deal with an ID without having to use that special runner eclipse is on the radar but probably not coming to 2017 parametrized tests parameterize by an extensions not there yet scenario tests kind of like with tests and G we have multiple steps with an ordering parallel execution these are things we're looking at so the last few minutes I want to talk about Spring Framework 5 Dido the new support for this so we actually have full support already for jana 5 with the spring extension in the latest milestone of spring 5.0 supports all of the core framework test connection we support you would like to see or you've seen in Jana 4 and no differences there but also additionally supports construction method injection via a daughter wired qualifier and at value so you can inject beans into a test method or before each method and stuff like that it also works with Spring Framework 4.3 there's no official built artifact for that that's published anywhere but you can check out the code on my github account spring test jana 5 you can build it locally and if there's enough demand we will actually consider backporting the support in spring 5 to spring 4.3 as gene at 5 moves towards GA so the spring extension again that's like the spring runner but for the jana 5 support just write a text in with a spring extension we have some composed annotations so you can simplify that you can just annotate a class with at spring jane and configure at spring jana web.config to have a standard application context or a web one and I will show some a quick demo here in a second but basically to show bringing everything together so if you want to latest and greatest cutting-edge you can use spring boot 1.4 with the new spring boot testing features you can use Jane at 5 milestone 2 and spring 5 milestone 1 and have that all working so here I have an example with some custom config doing exactly that I have my own custom annotation I like to do this on my projects just to reduce clutter so extending with spring extension please run Jane at five with spring spring boot test we saw this in the keynote with a mocked web environment auto-configure mahkum you see cool feature from spring boot test it's going to create the mocking me seat essences for me and I can can use that and I'm saying I want my test to be transactional so this is my custom annotation and I can use that across my my codebase so here we have an example I'm putting that together here's my gene at five tests class annotate it with that annotation getting all of this change of five spring boot magic together I have a method here setting a custom display name the home page should display more than ten objects so we have the mock MVC created for us automatically by spring boot inject it with Springs that are wired by the spring MVC integration testing support and then we can just use that mahkum you see perform a get request and our assert our expectations so this is basically the the simplest way the least amount of code you can write when you're on latest and greatest with spring boot 1.4 chain of five and spring five and that's actually all the time we have or lights two more demos but I think I'm not permitted so thank you for coming you have any questions come up and ask me you

Channel: SpringDeveloper

Views: 9,380

Rating: 4.7974682 out of 5

Keywords: Web Development (Interest), spring, pivotal, Web Application (Industry) Web Application Framework (Software Genre), Java (Programming Language), Spring Framework, Software Developer (Project Role), Java (Software), Weblogic, IBM WebSphere Application Server (Software), IBM WebSphere (Software), WildFly (Software), JBoss (Venture Funded Company), cloud foundry, spring boot, spring cloud, testing, junit, java 8, unit testing, unit test

Id: H7S0eXrZWZY

Length: 70min 24sec (4224 seconds)

Published: Tue Dec 06 2016