Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Excuse me for the title a little provocative.I'll take an example. Suppose you need to write a program to build a car. Here's a test program:
public void testCarBuilder()
{
expectedCar=someCar;
actualCar=carFactory.build(bigWhell, yellowBodyCar);
assertEqual(expectedCar, actualCar);
}
To know that to build a car, we need a function that will have the wheels and the carBody as parameter, it should at least have made an analysis of the program. This analysis can be done in natural language, UML or even directly write in the programming language!. We can write this analysis on a piece of paper, leaving it in our brain, or in writing to a file.
Analysis is already a skeleton of a program! So it was always at least one program skeleton write before the test!
Say that development task starts by writing tests is sybyllin, there is always a first skeleton program ( that we can call analysis) to write before. Unless someone shows me how the opposite may be possible.
Of ccourse some people write a test first.
In fact, you just wrote a test first in the question.
Your test has possibly then told you the code you need to write next, but you have discovered that after you wrote the test in the question.
I interpret your question as if you want to know how the design emerges when doing TDD.
In order to write a test you must define some boundary/surface/facade that the test should interact with. This design activity is done up front. The design that grows and changes is the one that is on the other side of that test boundary.
In your (trivial) example, the design that the tests help you discover is the one inside the carFactory. That's not very helpful, so I would say that your test is not that good.
There are different school within TDD. The one I practise advocate that you test from the outside and in. You choose a test boundary that is as close as possible to the system boundary. For instance, you let your test simulate button clicks in the user interface. When doing this, you are free to make changes to the design of the whole system on the other side of that button click.
In your example, why do you want to create a car? What did the user do to trigger this code, and how can the user tell that whatever she wanted to accomplish worked? That's what you should have in your test.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 days ago.
Improve this question
I am creating several scheduled tasks within my Laravel site using the schedule() function within the Console/Kernel object. It acceptable to place simple logic in the schedule() function (based on the explanation from the Laravel site):
$schedule->call(function () {
DB::table('recent_users')->delete();
})->daily();
However, if the logic needs to be more complicated (100 lines of code or more to decide which models to focus on) basic programming rules instructs us to break the code up into additional functions and classes, which can be then be called by schedule(). However, I am a bit confused as to where these functions/classes go. A few possibilities:
A Controller function, even though it does not use a route?
A trait, used by the Kernel?
Console command, even though it's never called from the console?
A helper?
(edit) Other classes that share the Kernel's namespace?
Another kind of class that functions like a Controller, but internally only? (Something that I am not aware of.)
Where do these classes/functions go?
====
There are many established patterns can be regarded as correct or incorrect, based on Laravel's intended use, regardless of opinion. Also, there are many valid ways in which Laravel can be used. Within this context, there are many opinions on the best way to do things, many of which could be considered correct. That said, there are framework design patterns which are beyond the scrutiny of opinion (for now.) We use routes to link URLs to Controllers (not jobs.) We access models from the controllers and not the other way around. My question is intended to discover an established pattern that I am not aware of, and not to debate opinions regarding these patterns.
Basically, I want to avoid building my site in a way that with prove blatantly embarrassing in the future, (especially regarding lesser well known site elements, such as jobs, scheduling and console commands) simply because I did not know Laravel facts.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I just started my college "adventures", and one of them is subject called operating systems. I must admit that the subject is the most boring ever. Last week, we got our first homework, and i do not know what to do as this is the first time ever i come up with Windows API functions or this topic in general. The task is very simple, we need to write very basic code in C that shows how does GetCurrentThread() work!!!???? I tried looking for solution online, but I could not find anything and our professor is not doing anything to help us. I found the use of functions like GetCurrentThreadID() but that is not what i need. Can somebody write simple program ( 20-30 lines of code ) which contains the use of this function (in C)?
Operating systems courses tend to suck because they take the simplest of concepts and try to make them convoluted.
Documentation for the GetCurrentThread () function is
https://learn.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-getcurrentthread
What it does not explain is that the return value for the function is a "handle." Windoze uses handles somewhat as pointers to objects but where you cannot access the object directly.
So you call GetCurrent() thread and it returns a "Handle to the Thread." That handle can then be used to do things with the thread.
Here are the things you can do:
https://learn.microsoft.com/en-us/windows/desktop/ProcThread/process-and-thread-functions
Some of these function pages have short examples.
So you could do:
print ("Thread ID: %d\n", GetThreadID (GetCurrentThread())) ;
and have the ID of the current thread.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I would like to know which is more efficient PERFORM PARA1. or PERFORM PARA1 THRU PARA1-EXIT.
PARA1.
XXXXXX.
PARA1-EXIT.
EXIT.
Presumably for PARA1-EXIT, the code following it is not really executable code. (I.e., it's something like an EXIT or CONTINUE) Also presumably, there is no other control flow to PARA1-EXIT (other than similar PERFORM statements.) Given that, using IBM Enterprise COBOL you can code it either way and get the same performance. So you should code it based on local coding standards or clarity.
Your first example really doesn't make any sense based on how PERFORM THRU works.
PERFORM X will perform paragraph/section X and PERFORM X THRU Z will perform everything between X and Z. So if I have the following
PERFORM X000 THRU Z000
X000.
some code
Y000.
more code
Z000.
even more code
All 3 paragraphs will be performed. So saying PERFORM X THRU X conceptually makes no sense. It may compile (depending on the compiler), but at the day end of the day it seems like you should just use a PERFORM X. Without knowing exactly what compiler you are running, we can't really say exactly what PERFORM X THRU X will do, but the only thing that makes logical sense is that it is synonymous with PERFORM X.
I have seen code before that had PERFORM X THRU X-EXIT, but X-EXIT only ever contained an EXIT statement. There may be some historical reason why things were coded this way, but I don't see any reason to in modern COBOL development.
I would strongly recommend against using PERFORM THRU because if anyone were to ever add code between the two paragraphs and didn't notice it was a PERFORM THRU, you will run into issues.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
How do you manage a massive (60+ pages) design (HTML/CSS) Project? Like what is your workflow? How do you set milestones?
Step 1. Simplify. Find a way to simplify what they're asking for. Often, this won't be apparent until you decompose and prioritize.
Step 2. Decompose. Inside every large project is a series of smaller projects waiting to get out. Break the big job into "sprints" that will build something you can release in a reasonable amount of time. 2-3 weeks per sprint (or less) is a good target.
Step 3. Prioritize. They want something first. Find out what that thing is and build that.
Step 4. Review and see if you can simplify further. Once you've decomposed and prioritized, you may see further opportunities to remove duplication, useless non-features, junk, fluff, bad ideas, and the like.
I recommend creating a work breakdown structure (WBS) to make sure you capture all of the tasks/deliverables required for your project..here's some basic tasks:
- develop a site map
- develop wireframes and mockups - and get client approval
- develop the main page and unique sub pages (assuming most sub pages are similiar in design and functionality, but different in content)
- inventory content needs
- build out primary page and 2-3 sub pages for final review/approval
- complete implementation of site but add content to the sub-pages
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So I've done unit testing some, and have experience writing tests, but I have not fully embraced TDD as a design tool.
My current project is to re-work an existing system that generates serial numbers as part of the companies assembly process. I have an understanding of the current process and workflow due to looking at the existing system. I also have a list of new requirements and how they are going to modify the work flow.
I feel like I'm ready to start writing the program and I've decided to force myself to finally do TDD from the start to end.
But now I have no idea where to start. (I also wonder if I'm cheating the TDD process by already have an idea of the program flow for the user.)
The user flow is really serial and is just a series of steps. As an example, the first step would be:
user submits a manufacturing order number and receives a list of serializable part numbers of that orders bill of materials
The next step is started when the user selects one of the part numbers.
So I was thinking I can use this first step as a starting point. I know I want a piece of code that takes a manufacturing order number and returns a list of part numbers.
// This isn't what I'd want my code to end up looking like
// but it is the simplest statement of what I want
IList<string> partNumbers = GetPartNumbersForMfgOrder(string mfgOrder);
Reading Kent Becks example book he talks about picking small tests. This seems like a pretty big black box. Its going to require a mfg order repository and I have to crawl a product structure tree to find all applicable part numbers for this mfg order and I haven't even defined my domain model in code at all.
So on one hand that seems like a crappy start - a very general high level function. On the other hand, I feel like if I start at a lower level I'm really just guessing what I might need and that seems anti-TDD.
As a side note... is this how you'd use stories?
As an assembler
I want to get a list of part numbers on a mfg order
So that I can pick which one to serialize
To be truthful, an assembler would never say that. All an assembler wants is to finish the operation on mfg order:
As an assembler
I want to mark parts with a serial number
So that I can finish the operation on the mfg order
Here's how I would start. Lets suppose you have absolutely no code for this application.
Define the user story and the business value that it brings: "As a User I want to submit a manufacturing order number and a list of part numbers of that orders so that I can send the list to the inventory system"
start with the UI. Create a very simple page (lets suppose its a web app) with three fields: label, list and button. That's good enough, isn't it? The user could copy the list and send to the inv system.
Use a pattern to base your desig on, like MVC.
Define a test for your controller method that gets called from the UI. You're testing here that the controller works, not that the data is correct: Assert.AreSame(3, controller.RetrieveParts(mfgOrder).Count)
Write a simple implementation of the controller to make sure that something gets returned: return new List<MfgOrder>{new MfgOrder(), new MfgOrder(), new MfgOrder()}; You'll also need to implement classes for MfgOrder, for example.
Now your UI is working! Working incorrectly, but working. So lets expect the controller to get the data from a service or DAO. Create a Mock DAO object in the test case, and add an expectation that the method "partsDao.GetPartsInMfgOrder()" is called.
Create the DAO class with the method. Call the method from the controller. Your controller is now done.
Create a separate test to test the DAO, finally making sure it returns the proper data from the DB.
Keep iterating until you get it all done. After a little while, you'll get used to it.
The main point here is separating the application in very small parts, and testing those small parts individually.
This is perfectly okay as a starting test. With this you define expected behavior - how it should work. Now if you feel you've taken a much bigger bite than you'd have liked.. you can temporarily ignore this test and write a more granular test that takes out part or atleast mid-way. Then other tests that take you towards the goal of making the first big test pass. Red-Green-Refactor at each step.
Small tests, I think mean that you should not be testing a whole lot of stuff in one test. e.g. Are components D.A, B and C in state1, state2 and state3 after I've called Method1(), Method2() and Method3() with these parameters on D.
Each test should test just one thing. You can search SO for qualities of good tests. But I'd consider your test to be a small test because it is short and focussed on one task - 'Getting PartNumbers From Manufacturing Order'
Update: As a To-Try suggestion (AFAIR from Beck's book), you may wanna sit down and come up with a list of one-line tests for the SUT on a piece of paper. Now you can choose the easiest (tests that you're confident that you'll be able to get done.) in order to build some confidence. OR you could attempt one that you're 80% confident but has some gray areas (my choice too) because it'll help you learn something about the SUT along the way. Keep the ones that you've no idea of how to proceed for the end... hopefully it'll be clearer by the time the easier ones are done. Strike them off one by one as and when they turn green.
I think you have a good start but don't quite see it that way. The test that is supposed to spawn more tests makes total sense to me as if you think about it, do you know what a Manufacturing Order number or a Part Number is yet? You have to build those possibly which leads to other tests but eventually you'll get down to the itty bitty tests I believe.
Here's a story that may require a bit of breaking down:
As a User I want to submit a manufacturing order number and receive a list of serializable part numbers of that orders bill of materials
I think the key is to break things down over and over again into tiny pieces that make it is to build the whole thing. That "Divide and conquer" technique is handy at times. ;)
Well well, you've hit the exact same wall I did when I tried TDD for the first time :)
Since then, I gave up on it, simply because it makes refactoring too expensive - and I tend to refactor a lot during the initial stage of development.
With those grumpy words out of the way, I find that one of the most overseen and most important aspects of TDD is that it forces you to define your class-interfaces before actually implementing them. That's a very good thing when you need to assemble all your parts into one big product (well, into sub-products ;) ). What you need to do before writing your first tests, is to have your domain model, deployment model and preferably a good chunk of your class-diagrams ready before coding - simply because you need to identify your invariants, min- and max-values etc., before you can test for them. You should be able to identify these on a unit-testing level from your design.
Soo, in my experience (not in the experience of some author who enjoys mapping real world analogies to OO :P ), TDD should go like this:
Create your deployment diagram, from the requirement specification (ofc, nothing is set in stone - ever)
Pick a user story to implement
Create or modify your domain model to include this story
Create or modify your class-diagram to include this story (including various design classes)
Identify test-vectors.
Create the tests based on the interface you made in step 4
Test the tests(!). This is a very important step..
Implement the classes
Test the classes
Go have a beer with your co-workers :)