AJR/TechradarDev
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Replace extranet links with cross refs

Browse Source 
Fixes #21
This commit is contained in:
Brian Hoffmann
2021-06-02 15:12:22 +02:00
parent 2724fbe2ce
commit d34c882cbc
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
radar/2017-03-01/gatlin.md
View File

@@ -8,7 +8,7 @@ quadrant: tools
Out of the box, Gatling comes with excellent support of the HTTP protocol that makes it a tool of choice for load testing any HTTP server. As the core engine is actually protocol agnostic, it is perfectly possible to implement support for other protocols. For example, Gatling currently also ships [JMS support](http://gatling.io/docs/current/). Out of the box, Gatling comes with excellent support of the HTTP protocol that makes it a tool of choice for load testing any HTTP server. As the core engine is actually protocol agnostic, it is perfectly possible to implement support for other protocols. For example, Gatling currently also ships [JMS support](http://gatling.io/docs/current/).
Gatling is built with [Scala Lang](https://extranet.aoe.com/confluence/display/knowledge/Scala+Lang) and [Akka](https://extranet.aoe.com/confluence/display/knowledge/Akka). By making good use of Scala's native language features (such as as the extensive type system), it makes writing tests feel natural and expressive, instead of writing load tests based on a DSL encoded in some special syntax. Gatling is built with [Scala Lang](/languages-and-frameworks/scala-lang.html) and [Akka](/languages-and-frameworks/akka.html). By making good use of Scala's native language features (such as as the extensive type system), it makes writing tests feel natural and expressive, instead of writing load tests based on a DSL encoded in some special syntax.
This allows us to use all native Scala features to work with, with the focus on the ability to structure your tests as pure code, and actually unit test your load tests. This allows us to use all native Scala features to work with, with the focus on the ability to structure your tests as pure code, and actually unit test your load tests.

2
radar/2017-03-01/spring-rest-docs.md
View File

@@ -4,6 +4,6 @@ ring: assess
quadrant: tools quadrant: tools
--- ---
[Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](https://extranet.aoe.com/confluence/pages/viewpage.action?pageId=86937862).  So you can be sure that your tests are inline with the documentation. [Spring REST Docs](https://projects.spring.io/spring-restdocs/) auto generates [Asciidoctor](http://asciidoctor.org/) snippets with the help of [Spring MVC Test](http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle#spring-mvc-test-framework) or [RestAssured](/tools/rest-assured.html).  So you can be sure that your tests are inline with the documentation.
At AOE, we use [Spring REST Docs](https://projects.spring.io/spring-restdocs/) to document our Rest Services and Hal Resources. We also use it to auto generate [Wiremock](/tools/wiremock.html) Stubs, so the consumer of the service can test against the exact API of the service. At AOE, we use [Spring REST Docs](https://projects.spring.io/spring-restdocs/) to document our Rest Services and Hal Resources. We also use it to auto generate [Wiremock](/tools/wiremock.html) Stubs, so the consumer of the service can test against the exact API of the service.