Package: robotframework-nl
robotframeworkNL - the onelinerrobotframeworkNL is a proving ground to boost Robot framework closer to Natural Language.IntroductionThis project is an extension toRobot frameworkand althoughRobot frameworkmade a very good step towards the goals ofkeyword-driven testingto make it readable for all stakeholders, there is still quite a lot of syntax involved that keeps test cases from really staying concise and to-the-point. In this project we will be introducing concepts to liftRobot frameworkto an even higher level.This second release introducesinline keywordsand a set ofCheck thatkeywords that help to vastly reduce the amount of${...}cluttering in your test cases. Combining these concepts helps to write a cleanerDomain Specific Languagearound yourdomain vocabulary.InstallationThe recommended installation method is usingpippip install --upgrade robotframework-nlAfter installation includerobotnlas library in your robot file to get access to the new keywords.FeaturesInline keywordsWe use the terminline keywordwhen a keyword is used as an argument to another keyword. In this case the inline keyword must return a value, which will then be used as the actual argument. Consider this  basic example where a keywords exists by the name'twelve'that just returns the number 12, which is then used in an action keyword operating an elevator.Using inline keywordRequest elevator floortwelveTraditional Robot${floor to request}=twelveRequest elevator floor${floor to request}To add support for inline keywords to your keywords, decorate your keyword with the@keyworddecorator from therobotnllibrary, instead of using the one fromrobot.api.deco.fromrobotnlimportkeywordclassmy_elevator:@keyword(name="Request elevator floor")defhandle_floor_request(target_floor):...Inline keywords are limited to a singlecellin Robot. This means that keywords that are used inline, cannot take any positional arguments when used inline. Embedded arguments are considered part of the same cell and do not have that limitation.Inline keywords are detected and processed at runtime. If a keyword is found that matches the argument's text, then that keyword will be executed and its return value used as the actual argument. When editing test cases, keyword highlighting can show which arguments are keywords when using a dynamic IDE likeRIDE(one that loads the keyword libraries into the IDE). Static editors will not be able to show this information, due to the runtime evaluation.Check thatUsingCheck thatkeywords offers a large reduction in the need for variables in your test case andless variables = less ${} syntax! It also encourages the use of theDoobcheckprinciple, which is an easy way to create maintainable keyword libraries.It let's you writeCheck thatTwo times6equalsThree times4instead of${calculation 1}=Two times${6}${calculation 2}=Three times${4}Should be equal${calculation 1}${calculation 2}Time constraintsCheck thatoffers support for executing checks that may take some time to complete. When using the optionalwithinargument, followed by a time duration,Check thatwill applysmart pollingto re-evaluate the expression and the keywords during the given period. Specifying the time limit is done using the standardRobot Framework time format. It is advised to use a realistic time duration. This sets the correct expectation for the reader and helps robotnl optimise its polling algorithm.Example using time constaintsRequest elevator at floor3Check thatelevator doors are closedwithin20 secondsCheck thatcurrent elevator floorequals3within1 minuteHybrid manual testingTo manually interact with your automated test run during testing or test case development, robotnl offers theCheck manualandCheck interactivekeywords. These keywords can be included at any point in the test case to suspend the test run at the current position for user input.Check Manualallows asking the tester a question. The question typically requests manual verification of an expected outcome. The answer will PASS or FAIL the test case, which is also reflected in the test report.Check interactiveprompts the user to input a keyword. You have access to all build-in, user and library keywords available to that test case. The keyword is executed, but failures will not fail the test case nor abort execution. This is ideal for trying out keywords and keyword variations without having to restart the test run every time.Keyword documentationFull documentation of the keywords offered byrobotnlcan be found here:Link to keyword documentationKeyword documentation is inlibdocformat, making it also directly available via intellisense in IDEs, likeRIDE.Proposed improvementsOption to mark keywords asoperator keywordsThis improvement affects theCheck thatkeywords and will remove the limitations on using inline keywords as arguments to operands. Without annotating operator keywords as such, it is not always possible to detect which keywords are intended as arguments to the operand and which one should be the operator.Explicit literal supportInclude a special annotation to express that something is not a keyword. For the odd case that a literal text needed as argument, also exists as a keyword. Alternativly the keyword receiving the argument can also use Robot's default keyword decorator.DoobcheckDoobcheck is short for Do-Observe-Check and the idea is simple, yet effective. Any keyword should have just one of these purposes, never more.Do keywords invoke an action. These keywords start with a verb and do not return anything.Observation keywords return information, without affecting state. These keywords typically start with a noun, the thing that is being observed.Check keywords are used for verifying information, typically using the result of an observation-keyword and an expected value. Thisrobotnllibrary offers genericCheck keywordsand operators. You can build new operator keywords in your own libraries to support any check you will ever need.